Thanks Jakub.

Essentially I wanted to address the integration of rights assignments to sudo and potentially other components. Sudo is a two factor item - first the authentication, then the filter of rules based on users or groups that determine whether the calling user actually has rights.

Integrating that into InteractiveLogonRight seems perfectly fine in a desktop environment, but one of the common themes in windows server hardening is locking down the InteractiveLogonRight and removing all but Domain and Local Administrators, or adding a DenyInteractiveLogonRight entry for the user groups, and granting only RemoteInteractiveLogonRight.

Our discussion involved a few theoreticals and some testing.

For example, let's say a user is a member of a group that has RemoteInteractiveLogonRight but Deny Local Logon. In this case, an administrator would expect that the user can log in and utilize sudo to access authorized privileged commands, similar to how in Windows, a user can log in using only this right and access other services, batch jobs, or privileged operations (assuming they're authorized) using RunAs and UAC. In this Scenario, however, sudo would not authenticate the user, since they are in Deny Local Logon.

This is a very common setup for servers - and Deny's always take precedence over their associated Allow in the context of the Local or Remote Interactive.

The discussion concluded with a concern on whether sudo and sudo-i should even be included in the rights policies given its two-factor nature. Would a security concern be raised by allowing sudo to authenticate a user regardless of these memberships? As far as I'm aware, sudo is called from an existing logon, cron, or other session.

Hope that sums everything we talked about up!

-Michichael

On Fri, Aug 8, 2014 at 1:58 PM, Jakub Hrozek <jhrozek@redhat.com> wrote:
On Tue, Aug 05, 2014 at 05:14:17PM -0400, Yassir Elley wrote:
>
>
> ----- Original Message -----
> > On Thu, Jul 31, 2014 at 01:58:06PM -0400, Yassir Elley wrote:
> > > ----- Original Message -----
> > > > On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > 4. Should we add the various gdm-* service names as interactive:
> > > > > gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin,
> > > > > gdm-smartcard
> > > > >
> > > > > 5. Should we add the screen savers as interactive: gnome-screensaver,
> > > > > kscreensaver
> > > >
> > > > I think we should check with Ray Strode (halfline on
> > > > IRC) about the and screensaver semantics. For instance in
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1104756#c16 Ray argued that
> > > > screensaver only 're-authenticates'.
> > > >
> > > > I tend to agree about the gdm-* services, but again, checking with Ray
> > > > might be a good idea. I think at least in the past, gdm would do some
> > > > funky stuff with non-password authentication, like sending the authtoks
> > > > to several different pam services and checking which ones would let the
> > > > user through..I'm not sure if it's still the case now after the Gnome
> > > > 3.x rewrite.
> > > >
> > > > What does gdm-launch-environment do?
> > > >
> > >
> > > I chatted with Ray Strode, who said we should provide defaults (of
> > > interactive) for gdm-password, gdm-smartcard, and gdm-fingerprint. The pam
> > > gnome-screensaver service has apparently been replaced with a gnome-shell
> > > lock screen (starting with RHEL 7). Even on RHEL 6, while the
> > > pam_acct_mgmt call is made when unlocking the gnome-screensaver, the
> > > results are apparently ignored (b/c the user already has a running
> > > session; the lock simply hides the gnome-shell display).
> >
> > Right, I found this out as well, it was a bit suprising to me, but meh,
> > the user's TGT would expire anyway..
> >
> > > He didn't think default values were needed for any of the other gdm related
> > > services, such as:
> > > * gdm-pin (no longer supported)
> > > * gdm-autologin (password-less login)
> > > * gdm-launch-environment (used to launch system session for gdm user to run
> > > login process)
> > > Note that there is no pam service simply named "gdm".
> > >
> > > On the other side, there seem to be four pam services related to kdm: kdm,
> > > kdm-np, kcheckpass, and kscreensaver. We should definitely include a
> > > default for kdm, but we probably don't care about kdm-np (no-password).
> > > Does anyone know how kscreensaver differs from kcheckpass (both have
> > > identical pam files, which essentially include system-auth for all calls
> > > (auth, account, session, password). Perhaps we should add defaults for
> > > both kcheckpass and kscreensaver.
> >
> > I'm sorry, I have no idea about KDE at all...I know that ltinkl@r.c does a
> > bit of KDE development, maybe he would get an idea.
> >
>
> Couldn't get in touch with ltinkl, but halfline pointed me to dvratil, who I chatted with instead. When a user tries to unlock the screen, kscreenlocker_greet calls kcheckpass, which calls pam_authenticate (but not pam_acct_mgmt). Also, kscreensaver is apparently legacy. So, among the KDE pam services, I think we should only provide a default for "kdm".
>
> Here is a summary of the pam service names for which I am planning on providing default logon rights (which can, of course, be overridden by configuration).
>
> Default = InteractiveLogonRight
> * login, su, su-l, sudo, sudo-i, gdm-password, gdm-fingerprint, gdm-smartcard, kdm
>
> Default = RemoteInteractiveLogonRight
> * sshd
>
> Default = NetworkLogonRight
> * ftp, samba
>
> Default = BatchLogonRight
> * crond
>
> Regards,
> Yassir.

We had a long and useful conversation about this topic on #sssd with
one of our users -- I'm adding him to the CC list so we can continue the
conversation.