[SSSD] should ad-gpo support additional logon rights?

Simo Sorce simo at redhat.com
Thu Jul 3 10:40:14 UTC 2014


On Wed, 2014-07-02 at 01:45 -0400, Yassir Elley wrote:
> 
> ----- Original Message -----
> > On Tue, 2014-07-01 at 01:50 -0400, Yassir Elley wrote:
> > > 
> > > ----- Original Message -----
> > > > On Sat, 2014-06-28 at 18:01 -0400, Yassir Elley wrote:
> > > > > 
> > > > > ----- Original Message -----
> > > > > > On Sat, 2014-06-28 at 01:20 -0400, Yassir Elley wrote:
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > On Thu, 2014-06-26 at 04:54 -0400, Yassir Elley wrote:
> > > > > > > > > Hi Simo,
> > > > > > > > > 
> > > > > > > > > I'd like to wrap up this discussion. I propose that we support
> > > > > > > > > only
> > > > > > > > > the InteractiveLogonRight (for the pam services you mentioned:
> > > > > > > > > "login", "*dm, "su*"), and on the RemoteInteractiveLogonRight
> > > > > > > > > (for
> > > > > > > > > the
> > > > > > > > > "ssh" pam service). We should not support the NetworkLogonRight
> > > > > > > > > since
> > > > > > > > > it is difficult to implement. Do you agree with this proposal?
> > > > > > > > 
> > > > > > > > Well I guess the answer depends on what do you plan to do for pam
> > > > > > > > services that are not listed ?
> > > > > > > > Do you always deny access ? Always permit ?
> > > > > > > 
> > > > > > > Since we would only support the InteractiveLogonRight and
> > > > > > > RemoteInteractiveLogonRight, we would always permit access for
> > > > > > > other
> > > > > > > pam
> > > > > > > services (because they would not be governed by gpo-based access
> > > > > > > control,
> > > > > > > and this would be clearly documented).
> > > > > > > 
> > > > > > > > 
> > > > > > > > I think a more reasonable workaround is to define a default type,
> > > > > > > > and
> > > > > > > > a
> > > > > > > > list of mappings.
> > > > > > > > 
> > > > > > > > If a PAM service is explicitly mapped you use that Right to
> > > > > > > > decide,
> > > > > > > > otherwise the decision falls back to the "default" Right.
> > > > > > > > Actually the default right could well be actually
> > > > > > > > NetworkLogonRight
> > > > > > > > or
> > > > > > > > InteractiveLogonRight or something else. As long as you can
> > > > > > > > change
> > > > > > > > the
> > > > > > > > mappings locally through some configuration that would allow the
> > > > > > > > admin
> > > > > > > > to add mappings according to their needs. Of course strong
> > > > > > > > guidance
> > > > > > > > on which mappings should be used for specific type of services
> > > > > > > > should
> > > > > > > > be
> > > > > > > > provided.
> > > > > > > > 
> > > > > > > > Simo.
> > > > > > > > 
> > > > > > > 
> > > > > > > I would prefer an approach which is more predictable for the AD
> > > > > > > admin.
> > > > > > > If
> > > > > > > we limit ourselves to InteractiveLogonRight and
> > > > > > > RemoteInteractiveLogonRight, the semantics are very clear (console
> > > > > > > login
> > > > > > > and remote login), allowing the AD Admin to be confident that any
> > > > > > > existing
> > > > > > > or future policy files containing those rights would be applied
> > > > > > > correctly
> > > > > > > and consistently, regardless of whether the machine is running
> > > > > > > Linux or
> > > > > > > Windows.
> > > > > > > 
> > > > > > > Also, I suspect AD admins would not like per-machine service
> > > > > > > mappings
> > > > > > > to be
> > > > > > > enforced, since that would defeat the purpose of enforcing a
> > > > > > > centralized
> > > > > > > policy in a consistent manner. When an AD admin made a change to a
> > > > > > > LogonRight policy setting, he would have to keep in mind that Linux
> > > > > > > machines may use the policy settings in ways that were not intended
> > > > > > > by
> > > > > > > the
> > > > > > > AD admin. For example, it would be problematic if a local admin
> > > > > > > decided
> > > > > > > to
> > > > > > > map "login" to NetworkLogonRight, or if some local admins mapped
> > > > > > > "ftp"
> > > > > > > to
> > > > > > > some LogonRight (but other local admins stayed with the default).
> > > > > > > This
> > > > > > > would result in inconsistent behavior between different Linux
> > > > > > > machines,
> > > > > > > and between Linux machines and Windows machines. Indeed, in the
> > > > > > > Windows
> > > > > > > world, the "local" per-machine GPO is given least priority in case
> > > > > > > of
> > > > > > > conflict (i.e. ou overrides domain, which overrides site, which
> > > > > > > overrides
> > > > > > > local). A solution to this problem of consistency would be to have
> > > > > > > a
> > > > > > > centralized GPO that maps pam services to LogonRights, but I don't
> > > > > > > think
> > > > > > > we need to implement that in the first release.
> > > > > > > 
> > > > > > > I think limiting ourselves to InteractiveLogonRight and
> > > > > > > RemoteInteractiveLogonRight would be less confusing and more
> > > > > > > predictable
> > > > > > > for AD admins (resulting in a greater likelihood of them deploying
> > > > > > > gpo-based access control). They would know that these two
> > > > > > > LogonRights
> > > > > > > would be enforced with the same semantics on Windows and Linux
> > > > > > > machines.
> > > > > > > They would also know that other LogonRights would not be enforced
> > > > > > > on
> > > > > > > Linux
> > > > > > > machines. Clean and crisp.
> > > > > > > 
> > > > > > > What do you think?
> > > > > > 
> > > > > > You make a good argument, but I am not entirely convinced you can
> > > > > > avoid
> > > > > > a local mapping unless you provide a GPO mapping, because the admin
> > > > > > must
> > > > > > be able to adjust mappings for new services installed on the box that
> > > > > > were not included in the upstream provided lists.
> > > > > > 
> > > > > > So if you already need to provide a way to augment mappings, you may
> > > > > > as
> > > > > > well handle all rights with reasonable defaults, and let the admin
> > > > > > decide whether they need to change stuff around.
> > > > > > 
> > > > > > Simo.
> > > > > > 
> > > > > 
> > > > > Allowing local admins to change stuff from underneath the AD admin's
> > > > > directives seems to violate the GPO philosophy of centralized,
> > > > > consistent application of policy. I don't think AD admins will find
> > > > > the gpo-based access control feature compelling, if it does not fit
> > > > > with their mental model of how GPO is supposed to work.
> > > > 
> > > > Sorry but I do not buy this argument. The whole GPO policy can be turned
> > > > on or off in sssd, so if admins do not control the boxes' sssd.conf file
> > > > they already know their policies are, at best, advisory.
> > > > 
> > > > >  As you know, LogonRights are existing Windows policy settings (not
> > > > > Linux-specific settings), so we really do have to honor the intent of
> > > > > the settings and the GPO framework.
> > > > 
> > > > Indeed, and in order to do that you need to be able to appropriately map
> > > > arbitrary services.
> > > > 
> > > > >  Having said that, I don't think we necessarily need to have a
> > > > > comprehensive implementation in the first release, especially if we
> > > > > think the GPO mapping is the correct solution (and if we think that we
> > > > > may implement that in a subsequent release).
> > > > 
> > > > We do not need the support as a GPO deliverable policy, but you need a
> > > > local mapping for the feature to be usable/testable IMO.
> > > > 
> > > > > I think the centralized mapping offered by a future GPO mapping would
> > > > > certainly allay the concerns of AD admins, as the power would remain
> > > > > in their hands and it would be applied consistently. Implementing
> > > > > local mapping now, and then adding a centralized mapping later would
> > > > > delay deployment and would add too much complexity IMO.
> > > > 
> > > > Why ? This is exactly the same as overlaying global policy on top of
> > > > local policy, I honestly do not see it as any more complex than needed.
> > > > 
> > > > > As for how to deal with new services (in the initial implementation),
> > > > > two ideas come to mind:
> > > > > 1) My preference would be that only services included in the upstream
> > > > > provided lists will be affected by gpo-based access control. Not very
> > > > > extensible, but that's OK if we intend on adding a GPO mapping in a
> > > > > future release.
> > > > 
> > > > Upstream runs on multiple OSs and Linux distributions, within those
> > > > there is already, I bet, enough conflict to make a single upstream list
> > > > unfeasible, as pam service names are somewhat arbitrary and customized
> > > > in different way especially for very distro-specific services like login
> > > > and graphical session managers.
> > > > 
> > > > > 2) Alternatively, we could go with a completely different proposal
> > > > > that would affect all pam services. Specifically, since remote login
> > > > > seems to be an uncommon pam service (we could only come up with
> > > > > "ssh"), we could declare that "ssh" maps to
> > > > > RemoteInteractiveLogonRight, and that *all* other services (including
> > > > > new services, custom services, etc), map to InteractiveLogonRight.
> > > > 
> > > > That would be wrong. I suspect one of the services you really want to
> > > > control, as a windows admin, is samba file services, and those must be
> > > > mapped to NetworkLogonRight.
> > > > And NEtworkLogonRight seem to be generally the most sensible default
> > > > once you exclude the services you know are interactive login shells.
> > > > 
> > > > >  While certainly not ideal (and not my preference), I think AD admins
> > > > > would find this easier to grok than local mappings, as it would be
> > > > > predictable and would allow policy authority to remain centralized,
> > > > > without central directives being manipulated by local admins.
> > > > 
> > > > If the admin doesn't grok what services run on a Linux box, they are
> > > > already doomed I would think. You need at least a passing understanding
> > > > of the policies you are going to set. We can *definitely* provide a good
> > > > default set, admins should not be required to provide explicit mappings
> > > > if the default works for them, but an unchangeable list will severely
> > > > reduce the utility of the feature.
> > > > 
> > > 
> > > OK. I forgot that local admins can disable gpo processing, so although
> > > AD admins may want centralized control over all domain computers
> > > (whether Windows or Linux), they may not be able to get it with this
> > > feature. Whether this will be a show-stopper for them remains to be
> > > seen. With that in mind, I agree that it makes sense to allow pam
> > > services to be mapped to logon rights.
> > > 
> > > With regard to the default set of mappings, I propose the following
> > > (based on previous emails).
> > >   login/*dm/su* maps to InteractiveLogonRight
> > >   ssh maps to RemoteInteractiveLogonRight
> > >   explicit mappings are honored
> > >   if the service is still unmapped, map it to NetworkLogonRight
> > 
> > I think we can take a page from FreeIPA's configuration, this is the
> > original list of services we provide by default for HBAC:
> > 
> > sshd
> > ftp
> > su
> > login
> > su-l
> > sudo
> > sudo-i
> > gdm
> > gdm-password
> > kdm
> > 
> > To which later updates added:
> > crond
> > vsftpd
> > proftpd
> > pure-ftpd
> > gssftp
> > 
> > Keep in mind that FreeIPA uses also service groups so all the ftp
> > services are grouped under a ftp group.
> > 
> > I think that we can add crond and samba to the first list and use that
> > as the default list.
> > 
> > > A few questions for you:
> > > * Does this list make sense?
> > 
> > Mostly, yes.
> > 
> > > * Should there be anything special about the default set, or can an
> > > admin re-map services from the default set (i.e. map "ssh" to
> > > NetworkLogonRight)?
> > 
> > I would use the following mappings.
> > 
> > InteractiveLogonRight:
> > 	su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdm
> > RemoteInteractiveLogonRight:
> > 	sshd
> > NetworkLogonRight:
> > 	ftp
> > 	samba
> > BatchLogonRight (?):
> > 	crond
> > 
> > I am not sure what to use as default fallback for any service that do
> > not match these.
> > 
> > There is a default "remote" service in Fedora, and there is a "other"
> > service which matches any unrecognized service IIRC.
> > 
> > Maybe we could map unknown stuff to ServiceLogonRight which poorly
> > translates to anything useful on Linux I think.
> > 
> > > * Should an admin be able to map a service to NULL (indicating that
> > > they don't want this service to be enforced by GPO policy)
> > 
> > So your suggestion would be the unrecognized services would simply be
> > ignored when it comes to GPO enforcing ?
> > 
> 
> Yes. By essentially providing an opt-in model for pam services (with
> respect to gpo enforcement), we would be requiring someone to make an
> informed decision about the service-to-Right mapping (rather than for
> us to make an arbitrary decision). When an unmapped service is
> encountered, we would emit a log message (so that the admin can add an
> explicit mapping, if he forgot to add one). I suspect the distros
> would be savvy enough to pre-populate the sssd.conf file with
> distro-specific service mappings, but an individual admin using their
> own custom pam service might need a nudge.
> 
> For example, if an admin forgets to explicitly map a custom service
> (or doesn't even know he needs to), it would be better for him to
> receive an "unrecognized service" message in the logs (which would
> hopefully remind him to add an explicit mapping, after giving it some
> thought), than for us to arbitrarily map the custom service to some
> default (which might even result in unintended access denials).
> 
> This would be in line with the opt-in model we are using for overall
> gpo-enforcement (b/c the default is "permissive"). An admin would have
> to intentionally set the mode to "enforcing", and would have to
> intentionally provide explicit mappings for non-default services (or
> even to change a default service mapping).
> 
> What do you think?

I generally lean on deny by default, sounds like a saner approach.
Especially because admins already have to change it to enforcing
manually, so they know what they are doing and it will not come as a
surprise.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list