----- Original Message -----
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.
OK. That's a good point. They already have to make a conscious decision to set gpo to
enforcing. Let's stick with deny by default, then.
Regards,
Yassir.