----- Original Message -----
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.
The current design of the mapping mechanism groups pam service names by LogonRights, by
introducing several options of the form:
ad_gpo_map_{interactive, remote_interactive, etc}
A comma-separated list of PAM service names for which access control
is evaluated with the help of the AD {Interactive, RemoteInteractive, etc} Logon
Right.
Default: login, su, su-l, gdm, kdm
The current design also has:
ad_gpo_default_rights
This option defines how access control is evaluated for PAM
services which are not explicitly listed in one of the ad_gpo_map_*
options. Allowed values are 'interactive', 'remote_interactive',
'network', 'batch' and 'service' to do the evaluation based on
the
corresponding AD Logon Right. Additionally 'permit' and 'deny' can
be used to either always grant or reject access for PAM services that
are not explicitly listed in one of the ad_gpo_map_* options.
Default: deny
It sounds like we need two more options to round this out:
ad_gpo_map_permit (string)
A comma-separated list of PAM service names for which GPO-based access is always
granted, regardless of any AD Logon Rights.
Default: sudo, sudo-l
ad_gpo_map_deny (string)
A comma-separated list of PAM service names for which GPO-based access is always
denied, regardless of any AD Logon Rights.
Default: null
Would this address the concerns raised?
Also, do we still want to keep "su" and "su-l" in the Interactive
bucket?
Regards,
Yassir.