Red Hat Bugzilla – Bug 882385
Something is logging in under gdm account
Last modified: 2013-02-04 11:50:46 EST
Description of problem:
Some piece of software is logging in as gdm. This is showing up in the audit trail:
# ausearch --start today -m login -ul gdm
time->Fri Nov 30 06:22:18 2012
type=LOGIN msg=audit(1354274538.112:83): login pid=1323 uid=0 old auid=4294967295 new auid=42 old ses=4294967295 new ses=1
I don't know what is doing this, but its messing up the audit trail. Only user logins under a real user account should set a loginuid, all daemons must stay -1. Any help in hunting this down and changing the behaviour would be appreciated.
Anyone looking into this? The audit trail still shows something is logging in under the gdm account when nothing should be. This seems to coincide with a user logging in. Thanks.
the login screen runs in its own confined session. these sessions are visible with
$ loginctl list-sessions
SESSION UID USER SEAT
1 42 gdm seat0
$ loginctl show-session 1
Timestamp=Fri, 2013-02-01 13:22:28 EST
Note, the login class is "greeter".
We could remove pam_loginuid from /etc/pam.d/gdm-launch-environment but then I fear logind would not be able to track login sessions anymore.
The loginuid is for actual logins by people. Its not intended for system use. All daemons should have loginuid set to -1, meaning that its a system process and not related to activity by a person.
The only times that daemons or system processes should have a loginuid other than -1 is when an account has been hacked. Meaning that perhaps due to a misconfiguration, ftp (or any system account) has a valid shell instead of nologin and someone tried it at a login prompt and got system access. This is used by intrusion detection systems to identify suspicious system activity.
pam_loginuid should be placed in a point where a user is logging in and has already gave their password for their account. This used to be working correctly back in F-14, not sure when it changed, but its definitely wrong now. Thanks.
I've done a little testing and logind seems to be able to cope with login session not having kernel session ids.
I've pushed this:
We may have to revisit this later if problems crop up.