This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 881930 - please remove lastlog from the default pam stack
please remove lastlog from the default pam stack
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-29 14:37 EST by Matthias Clasen
Modified: 2013-09-30 10:13 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-07 23:33:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Matthias Clasen 2012-11-29 14:37:21 EST
It causes unpleasant flicker on the gdm login screen, and you can't read it anyway because it is gone in a split second. Here is the conversation I had with Ray about it:

<mclasen> halfline: while I see you talking about 'chatty pam' in another channel...
<mclasen> I notice that when I login, I see a 'Last login: some date' message appear in the shell login screen for a split second
<mclasen> its more noticable when things are very slow after you've dropped caches
<mclasen> but I can also see it in normal login, if I look closely
<halfline> yea that got added recently
<halfline> look at /etc/pam.d/postlogin
<halfline> we should probably get it removed
<mclasen> yes, I find that quite unacceptable
<mclasen> I don't care if we show that for gettys
<mclasen> but not in gdm, where is only flickering in for a split second while we are animating
<halfline> mclasen: if you prod t8m, he'll probably take it out
<halfline> or move it to /etc/pam.d/login and /etc/pam.d/ssh
Comment 1 Tomas Mraz 2012-11-30 14:00:50 EST
I'd really prefer if gdm could be fixed to properly display the messages from PAM if there are any. But for F18 I can understand that this is too late now. So I (only for F18) will skip pam_lastlog in the configuration.

Note that it is very frequent requirement to be able to display information about last login and previous bad login attempts.
Comment 2 Matthias Clasen 2012-11-30 14:16:51 EST
This is not the right way to display that kind of message.

It is not part of the login process, but informs you about the last login. If anything, it should be displayed as a notification after login - but only if there is really reason to be suspicious.
Comment 3 Steve Grubb 2012-11-30 14:39:43 EST
Actually, there are security guidelines that need to be followed. Between authenticating and being free, people need to 1) see a consent to being monitored screen and agree to it, disagreeing logs them back out. 2) See the number of failed login attempts since the last good one as well as the date and time of the last good login. This has to stay on screen until dismissed.

How these are done, I don't really care too much. But they are real requirements for every login, not just suspicious ones.
Comment 4 Steve Grubb 2012-11-30 14:41:46 EST
Of course this can default to not used for home users...
Comment 5 Tomas Mraz 2012-11-30 14:46:01 EST
(In reply to comment #2)
> It is not part of the login process, but informs you about the last login.
> If anything, it should be displayed as a notification after login - but only
> if there is really reason to be suspicious.

As you can read above from Steve - there are requirements that the message must be displayed until explicitly dismissed by the user.

Of course gdm could/should collect the post-auth message(s) and forward them to the gnome session for display.

But there is also the requirement to be able to display messages pre-auth that have to be explicitly ack-ed by user which has to be done by gdm anyway.
Comment 6 Matthias Clasen 2012-12-03 17:29:03 EST
Those requirements have very little relevance for Fedora, which is almost entirely in the domain of home users.

And I don't see how the current implementation meets Steve's requirements at all, considering the message only flickers through for a split second, and there is no way for the user to consent to anything.

Please, lets just remove this and discuss a proper implementation.
Comment 7 Bill Nottingham 2012-12-03 18:04:25 EST
(In reply to comment #3)
> Actually, there are security guidelines that need to be followed. Between
> authenticating and being free, people need to 1) see a consent to being
> monitored screen and agree to it, disagreeing logs them back out. 2) See the
> number of failed login attempts since the last good one as well as the date
> and time of the last good login. This has to stay on screen until dismissed.

I'm curious what security requirements these are - these don't seem to be part of any planned feature list, they were not part of prior releases, and we need these sort of things run through a proper process so we can coeherently account for them.
Comment 8 Fedora Update System 2012-12-05 18:11:55 EST
pam-1.1.6-3.fc18.1,authconfig-6.2.5-1.fc18.2 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/pam-1.1.6-3.fc18.1,authconfig-6.2.5-1.fc18.2
Comment 9 Fedora Update System 2012-12-06 15:18:55 EST
Package pam-1.1.6-3.fc18.1, authconfig-6.2.5-1.fc18.2:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing pam-1.1.6-3.fc18.1 authconfig-6.2.5-1.fc18.2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-19874/pam-1.1.6-3.fc18.1,authconfig-6.2.5-1.fc18.2
then log in and leave karma (feedback).
Comment 10 Fedora Update System 2012-12-07 23:33:48 EST
pam-1.1.6-3.fc18.1, authconfig-6.2.5-1.fc18.2 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 11 Allan Day 2013-09-30 09:38:09 EDT
(In reply to Bill Nottingham from comment #7)
> (In reply to comment #3)
> > Actually, there are security guidelines that need to be followed. Between
> > authenticating and being free, people need to 1) see a consent to being
> > monitored screen and agree to it, disagreeing logs them back out. 2) See the
> > number of failed login attempts since the last good one as well as the date
> > and time of the last good login. This has to stay on screen until dismissed.
> 
> I'm curious what security requirements these are - these don't seem to be
> part of any planned feature list, they were not part of prior releases, and
> we need these sort of things run through a proper process so we can
> coeherently account for them.

I'd like to reiterate this request. I'd like to design this to make sure that we fulfill these requirements (upstream bug is https://bugzilla.gnome.org/show_bug.cgi?id=708846 ), and it would be really helpful to have some more details.
Comment 12 Steve Grubb 2013-09-30 10:13:02 EDT
The first requirement is that during login, users of some systems may have to consent to being monitored. Meaning they have to click on OK and also have a choice to disagree. If they disagree, they must be logged back out. If they agree, they proceed to establish the session. The text they agree to must be configurable as different organizations have differing legal requirements and they can change over time. This is required for example by DISA STIG GEN000402. Also, the NIST USGCB security guidelines also require it. This should also probably become an audit event so there is a "legal" trail.

Second, after login, the number of failed attempts since the last good login and the time/date of the last login must be displayed. This can be found in NIST SP800-53, AC-9 PREVIOUS LOGON (ACCESS) NOTIFICATION: The information system notifies the user, upon successful logon/access, of the number of unsuccessful logon/access attempts since the last successful logon/access.

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