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
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!
On Fri, Aug 8, 2014 at 1:58 PM, Jakub Hrozek <jhrozek(a)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
> > > > > gdm-autologin, gdm-fingerprint, gdm-launch-environment,
> > > > > gdm-smartcard
> > > > >
> > > > > 5. Should we add the screen savers as interactive:
> > > > > 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
> > > > screensaver only 're-authenticates'.
> > > >
> > > > I tend to agree about the gdm-* services, but again, checking with
> > > > might be a good idea. I think at least in the past, gdm would do
> > > > funky stuff with non-password authentication, like sending the
> > > > to several different pam services and checking which ones would
> > > > user through..I'm not sure if it's still the case now after
> > > > 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.
> > > gnome-screensaver service has apparently been replaced with a
> > > 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
> > > services, such as:
> > > * gdm-pin (no longer supported)
> > > * gdm-autologin (password-less login)
> > > * gdm-launch-environment (used to launch system session for gdm user
> > > 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-np, kcheckpass, and kscreensaver. We should definitely include a
> > > default for kdm, but we probably don't care about kdm-np
> > > Does anyone know how kscreensaver differs from kcheckpass (both have
> > > identical pam files, which essentially include system-auth for all
> > > (auth, account, session, password). Perhaps we should add defaults
> > > both kcheckpass and kscreensaver.
> > I'm sorry, I have no idea about KDE at all...I know that ltinkl(a)r.c
> > 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
> Default = InteractiveLogonRight
> * login, su, su-l, sudo, sudo-i, gdm-password, gdm-fingerprint,
> Default = RemoteInteractiveLogonRight
> * sshd
> Default = NetworkLogonRight
> * ftp, samba
> Default = BatchLogonRight
> * crond
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