Bug 882385

Summary:	Something is logging in under gdm account
Product:	[Fedora] Fedora	Reporter:	Steve Grubb <sgrubb>
Component:	gdm	Assignee:	Ray Strode [halfline] <rstrode>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	high
Version:	18	CC:	jrieden, rstrode
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-04 16:50:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	853068

Description Steve Grubb 2012-11-30 20:10:30 UTC

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 16:18:34 UTC

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 18:25:53 UTC

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
Id=1
Timestamp=Fri, 2013-02-01 13:22:28 EST
TimestampMonotonic=8555777424
DefaultControlGroup=name=systemd:/user/gdm/1
VTNr=1
Display=:0
Remote=no
Service=gdm-launch-environment
Leader=4272
Audit=1
Type=x11
Class=greeter
Active=yes
State=active
KillProcesses=no
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
Name=gdm

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 14:58:48 UTC

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 16:50:46 UTC

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:

http://git.gnome.org/browse/gdm/commit/?id=f46bd9712e9452068199ceb44ed414cb8e408ce7

We may have to revisit this later if problems crop up.