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.");
> (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."
Perhaps..
2. We should make the option names describe the contents of the option. For
example, "ad_gpo_service_names_interactive"
I actually liked the "_map_" better. The semantics is what UNIX services
you map onto interactive or remote GPO service groups.
3. The default for ad_gpo_map_network should also include "samba" (in addition
to "ftp")
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
I think we should check with Ray Strode (halfline on
IRC) about the and screensaver semantics. For instance in
https://bugzilla.redhat.com/show_bug.cgi?id=1104756#c16 Ray argued that
screensaver only 're-authenticates'.
I tend to agree about the gdm-* services, but again, checking with Ray
might be a good idea. I think at least in the past, gdm would do some
funky stuff with non-password authentication, like sending the authtoks
to several different pam services and checking which ones would let the
user through..I'm not sure if it's still the case now after the Gnome
3.x rewrite.
What does gdm-launch-environment do?
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."
Could we do with only providing mapping of PAM services to Logon Rights
and denying the rest?
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)
I don't like if the fallback or default includes a 'permit' right, then the
semantics smell too much like deny lists which are almost always a bad idea.
What exactly do you mean by opt-in model? The 'permissive' option by
default?