----- Original Message -----
On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
>
>
> ----- Original Message -----
> > On Wed, Jul 02, 2014 at 01:45:00AM -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?
> >
> > Explaining on the logs why access to a service was granted or denied is
> > always a good idea. I guess those messages will fell in the
> > audit-messages category but currently SSSD does not treat audit messages
> > specially. Maybe we should start simple and just add an alias to the
> > DEBUG macro called AUDIT? Later on we can start handling them differently
> > than other debug messages but we will already have (at least for newer
> > code) a label in the code where audit information originates.
> >
>
> Can't we just use the sss_log_ext() function that I introduced recently (in
> util.h). It is currently used only in ad_gpo.c (to deal with gpo
> permissive mode). Note that this function emits a syslog message to the
> security log (with or without journald). It does not emit a message to the
> debug log (although the code separately emits a debug log message).
>
> from ad_gpo.c:
> sss_log_ext(SSS_LOG_WARNING, LOG_AUTHPRIV, "Warning: user would " \
> "have been denied GPO-based logon access if the " \
> "ad_gpo_access_control option were set to enforcing " \
> "mode.");
sure, having it in the syslog/journal might be even better then in the
SSSD logs. My point is to make it clear that it is an audit message and
not just a warning or error messages.
How are you defining "audit message"? Does it mean a status message that
doesn't mean anything is wrong (no warning, no error), but that it would be useful for
the admin to know?
>
> > (Sorry for hijacking this tread, I'll return now to the gpo and services
> > discussion :-)
> >
> > I'd like to try to summarize the discussion with a hypothetical man page
> > section of new config options:
> >
> > ad_gpo_map_interactive (string)
> > A comma-separated list of PAM service names for which access control
> > is evaluated with the help of the AD Interactive Logon Right.
> >
> > Default: su, login, su-l, sudo, sudo-i, gdm, gdm-password, kdm
> >
> > ad_gpo_map_remote_interactive (string)
> > A comma-separated list of PAM service names for which access control
> > is evaluated with the help of the AD Remote Interactive Logon Right.
> >
> > Default: sshd
> >
> > ad_gpo_map_network (string)
> > A comma-separated list of PAM service names for which access control
> > is evaluated with the help of the AD Network Logon Right.
> >
> > Default: ftp
> >
> > ad_gpo_map_batch (string)
> > A comma-separated list of PAM service names for which access control
> > is evaluated with the help of the AD Batch Logon Right.
> >
> > Default: crond
> >
> > ad_gpo_map_service (string)
> > A comma-separated list of PAM service names for which access control
> > is evaluated with the help of the AD Service Logon Right.
> >
> > Default: Not set
> >
> > ad_gpo_default_rights (string)
> > 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 those PAM
> > services.
> >
> > Default: deny
> >
> > bye,
> > Sumit
>
> Thanks!! This is a great start! Very helpful.
>
> A few comments:
>
> 1. We should tweak the wording a bit (and also mention the corresponding
> Deny Rights). For example, "A comma-separated list of PAM service names
> for which access control is evaluated based on the AD BatchLogonRight and
> DenyBatchLogonRight policy settings."
>
> 2. We should make the option names describe the contents of the option. For
> example, "ad_gpo_service_names_interactive"
sure, feel free to improve this, it is just a first suggestion.
>
> 3. The default for ad_gpo_map_network should also include "samba" (in
> addition to "ftp")
I'm not aware of a "samba" PAM service.
I think Simo suggested adding the "samba" PAM service to NetworkLogonRight.
Simo, can you clarify what you meant?
>
> 4. Should we add the various gdm-* service names as interactive:
> gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin,
> gdm-smartcard
>
> 5. Should we add the screen savers as interactive: gnome-screensaver,
> kscreensaver
sure, I'm not sure if some of the gdm-* option are Fedora/RHEL specific,
but even if it is it won't hurt on other distributions.
>
> 6. I don't like overloading the ad_gpo_default_rights option so as to
> include either a Right or a permit/deny. In fact, I don't think a default
> Right is needed at all (but the permit/deny might be useful). Assuming
> there are only a handful of unrecognized rights, there is already a
> convenient mechanism to specify explicit mappings. We can use a
> non-overloaded option that can be used to specify permit/deny semantics
> for unmapped service names. I think this would be more understandable. For
> example: "ad_gpo_service_names_unmapped_action (string): This option
> defines how access control is evaluated for PAM services which are not
> explicitly listed in one of the ad_gpo_service_names_* options. Values of
> 'permit' and 'deny' can be used to either always grant or always
reject
> access for those PAM services."
I had the following use-case in mind. Since the mapping cannot be managed
in AD (yet) admins might want to cover all PAM services in a single
right, e.g. BatchLogonRight. To not force the admin to list all PAM
servies (the known, the known unknown and the unknown unknown :-) in the
BatchLogonRight specific option I thought allow the right in the default
option is the nices solution than allowing a catch all like '*' in the
right specific options.
I think this could be useful, although, with wildcards, admins may just pick an arbitrary
right as the default right (i.e. they may not be forced to think about which right does
this service name really correspond to, which they would have had to do if we required
explicit mappings). My primary objection to this proposal was in overloading the
ad_gpo_default_rights option, which could take the name of a Right as a value, or a
permit/deny as a value. This seems unusual. Do we do it anywhere else in sssd?
Perhaps, we could just split ad_gpo_default_rights option into two options, and it would
be an error to set both options. Maybe:
* "ad_gpo_default_right" takes the name of a right ("interactive",
"network", etc) as a value
* "ad_gpo_service_names_unmapped_action" takes "permit" or
"deny" as a value
Or are the number of gpo options already out of control?
>
> 7. I think the default for the default/unmapped option should be "permit"
> rather than "deny" (to be consistent with the opt-in model for overall
gpo
> processing)
My thinking here is that access control in SSSD in general is opt-in
because the default access provider it 'permit'. If you change this
e.g. by activating the IPA access provider you delegate the decision if
access is granted or not to an external source. If the external source
cannot make a decision it is an error from the SSSD perspective and
access should be denied in case of an error.
GPO is special here, because the external source cannot decide on its
own but needs the local PAM service mapping as well. But I still think
'deny' is a good default because it will help to faster recognise that
there is an unconfigured PAM service.
OK. Good point. I agree that we should deny by default.
Regards,
Yassir.