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