On Mon, 2014-08-11 at 21:48 +0200, Jakub Hrozek wrote:
On Mon, Aug 11, 2014 at 03:44:34PM -0400, Simo Sorce wrote:
> On Mon, 2014-08-11 at 21:06 +0200, Jakub Hrozek wrote:
> > On Mon, Aug 11, 2014 at 12:10:28PM -0400, Simo Sorce wrote:
> > > On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
> > > >
> > > > In our case, when a user calls "sudo ls", I think it is a
three-step
> > > > procedure:
> > > > 1) sudo calls pam_authenticate to authenticate the user
> > > > 2) sudo calls pam_acct_mgmt to make sure that the account is not
> > > > locked, that the ldap/gpo policies permit the user to run sudo, etc
> > > > 3) sudo refers to /etc/sudoers to determine if it can perform the
sudo
> > > > action (i.e. "ls").
> > > >
> > > > The GPO Logon Rights relate to step (2) of this procedure.
> > >
> > > Except we do not have a logon right in windows that really matches what
> > > sudo is/does ... besiodes given sudo does its own authorization checks,
> > > what's the point of 2 ?
> >
> > I assume by 'its own authorization checks', you mean /etc/sudoers,
> > right?
>
> Yes.
>
> > Anyway, this is not something we can influence, can we? /etc/pam.d/sudo
> > includes system-auth on Fedora, so account management is going to be
> > called...
>
> But we can map sudo and sudo-l targets in the gpo code as "always
> allow".
Right, we just need to be very careful about documenting this (see the
e-mail I just sent) to make sure users of any similar PAM services don't
suffer.
Off-hand I can think of Quest -- don't they include a sudo version of
their own that might be affected?
There are tons of sudo like apps we need to allow to exist in fact,
which is why a tweakable mapping between PAM service names and policies
is a requirement IMO.
Simo.
--
Simo Sorce * Red Hat, Inc * New York