Bug 1664147

I'd say that at least in the non-interactive session the sudo should just ignore all the output of the pam modules. Setting PAM_SILENT flag might not be sufficient as modules can ignore the flag (such as pam_lastlog with showfailed option).

The question also is whether pam_lastlog should be called at all from the sudo PAM configuration. Traditionally the sudo calls were not treated as full login sessions.

(In reply to Tomas Mraz from comment #3)
> I'd say that at least in the non-interactive session the sudo should just
> ignore all the output of the pam modules. Setting PAM_SILENT flag might not
> be sufficient as modules can ignore the flag (such as pam_lastlog with
> showfailed option).
> 
> The question also is whether pam_lastlog should be called at all from the
> sudo PAM configuration. Traditionally the sudo calls were not treated as
> full login sessions.

This change was introduced due to https://bugzilla.redhat.com/show_bug.cgi?id=1502630.

Proper solution is probably to maintain own pam stack config files but it breaks the system-wide settings.

Tomas, what would be the best way to go, looking from pam POV?

(In reply to Tomas Mraz from comment #3)
> I'd say that at least in the non-interactive session the sudo should just
> ignore all the output of the pam modules. Setting PAM_SILENT flag might not
> be sufficient as modules can ignore the flag (such as pam_lastlog with
> showfailed option).

Isn't this a bug in pam_lastlog that would be fixed by:
https://github.com/linux-pam/linux-pam/pull/91

It we have other modules with such issues, we can solve the issue in the 
specific modules. This will give users the power to configure what they
want.

I am afraid there is no "best" way as all of them have some drawbacks.

IMO, sudo should be modified to suppress all the messages from PAM in the non-interactive mode. Or even better it should suppress them only if the pam session calls finish successfully in case there is some error message output in the error case. It of course means sudo would have to cache all the messages from the modules and output them only after it knows the return status.

However that does not fix the issue of resetting the bad login output for other login sessions if sudo is invoked.

That would be fixed by modifying postlogin in both pam and authconfig to have:

session     [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service != su service != su-l quiet

Alternatively sudo should not have 'session include postlogin' in /etc/pam.d/sudo. That would effectively fix everything and I am not sure it is actually that big problem. But of course the latent problem of possible modifying command output for non-interactive sudo calls would still stay but it would not pronounce with the default configuration.

(In reply to Nir Soffer from comment #5)
> (In reply to Tomas Mraz from comment #3)
> > I'd say that at least in the non-interactive session the sudo should just
> > ignore all the output of the pam modules. Setting PAM_SILENT flag might not
> > be sufficient as modules can ignore the flag (such as pam_lastlog with
> > showfailed option).
> 
> Isn't this a bug in pam_lastlog that would be fixed by:
> https://github.com/linux-pam/linux-pam/pull/91
> 
> It we have other modules with such issues, we can solve the issue in the 
> specific modules. This will give users the power to configure what they
> want.

The thing is that pam_lastlog should not be called from sudo anyway. So yes, pam_lastlog could be fixed (and should be at least upstream to behave correctly when PAM_SILENT flag is passed in) but the problem would not be fixed "in general".

I filed bug 1665679 for the PAM_SILENT issue and set it to block this bug.

We need to backport both trivial patches for sudo and pam, or change sudo
in another way so it does not use pam_lastlog unless using running a shell
(e.g. sudo -s).

In my opinion "fixing" it this way is wrong. Not in the sense that adding the PAM_SILENT flag is wrong but that it does not fully fix the problem. The sudo regular or non-interactive call will clear the Bad login message and update the last login message and this is clearly wrong as sudo call is not a login session. Pam_lastlog module is clearly not supposed to be called from sudo at all. I propose to completely drop the call of postlogin configuration from the /etc/pam.d/sudo configuration.

Created attachment 1520883 [details]
proposed patch

(In reply to Nir Soffer from comment #0)
> This configuration probably try to satisfy:
> http://people.redhat.com/swells/scap-security-guide/tables/table-rhel7-
> nistrefs-ospp-rhel7.html
> (See CCE-27275-7 Set Last Logon/Access Notification) 
>
> ... snip ...
> 
> Steps to Reproduce:
> 1. Add "session     required      pam_lastlog.so showfailed" to 
>    /etc/pam.d/system-auth

Why system-auth and not postlogin as per the linked USGCB rule?

(In reply to Daniel Kopeček from comment #19)
This is was found in a customer system. I don't know why and how it was
configured like this.

Do you think this configuration is invalid?

(In reply to Nir Soffer from comment #20)
> (In reply to Daniel Kopeček from comment #19)
> This is was found in a customer system. I don't know why and how it was
> configured like this.
> 
> Do you think this configuration is invalid?

Well, according to the USGCB rule and what Tomas said, yes, I think so.
If not invalid, then not supported for sure.