Bug 882385 - Something is logging in under gdm account
Something is logging in under gdm account
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
Unspecified Unspecified
high Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
Depends On:
Blocks: 853068
  Show dependency treegraph
Reported: 2012-11-30 15:10 EST by Steve Grubb
Modified: 2013-02-04 11:50 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-02-04 11:50:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 693152 None None None Never

  None (edit)
Description Steve Grubb 2012-11-30 15:10:30 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.
Comment 1 Steve Grubb 2013-01-30 11:18:34 EST
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.
Comment 2 Ray Strode [halfline] 2013-02-01 13:25:53 EST
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.
Comment 3 Steve Grubb 2013-02-04 09:58:48 EST
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.
Comment 4 Ray Strode [halfline] 2013-02-04 11:50:46 EST
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.

Note You need to log in before you can comment on or make changes to this bug.