[SSSD] Design Discussion: Restricting domains per PAM service

Jakub Hrozek jhrozek at redhat.com
Tue Sep 23 14:54:45 UTC 2014


On Tue, Sep 23, 2014 at 10:03:36AM -0400, Simo Sorce wrote:
> On Tue, 23 Sep 2014 15:39:19 +0200
> Jakub Hrozek <jhrozek at redhat.com> wrote:
> 
> > On Tue, Sep 23, 2014 at 09:07:06AM -0400, Simo Sorce wrote:
> > > > Simo, does the design page reflect the discussion accurately? Can
> > > > we start on the implementation?
> > > 
> > > Yes I made a minor edit to the password change clause, should we
> > > add a test point about it too ?
> > > 
> > > Simo.
> > 
> > Ah, thank you very much, that much clearer. Yes, I agree we should
> > add a test case -- so far I added one that says pretty much what you
> > said in the implementation phase. I'm not sure if we need more,
> > because normally you're not allowed to chpass as anyone else than
> > self and IIRC we explicitly drop password change requests from root.
> > 
> > In another conversation with Dmitri, I proposed two other changes I'd
> > like to discuss:
> > 
> > Normally, the list of allowed domains for untrusted users should be
> > 'all', which is the current behavirour. However, if the trusted user
> > list is set, we should default to 'none' and require that access to
> > untrusted domains is set explicitly.
> 
> Why ? I do not think we really need to have this, having defaults
> change based on other parameters may confuse people.
> I would rather just document that you should change the other value in
> the man page and documentation.

I'm afraid administrators will not read the docs in full. If the default
is 'allow all' they might just append the domains=foo parameter to the
pam_sss.so line and think that the pam module can only contact a certain
domain. In reality, all untrusted processes would still be able to
access all domains.

Forcing the admin to change the list of domains accessible to untrusted
users would make sure they explicitly spell out the domains..

> 
> > The other change is a new [domain] section option, maybe
> > "allow_untrusted" that would make it possible to augment the global
> > list of domains allowed for untrusted users. While the option doesn't
> > have too much use now, it will be very useful when we allow merging
> > configs and defining a new domain just by dropping a file.
> 
> I would defer this to when we have actual requests for it.
> I am not necessarily opposed but it will be confusing. You see a list
> of domains (or even 'none') and then you have to (at least
> mentally) parse all the code snippets to find out who can do what. 
> 
> I think domain snippets, in general, should not influence other
> services behavior, but just define the domain itself.

OK, we can defer. I will make a note to the ticket that describes
including configuration so that we don't forget.



More information about the sssd-devel mailing list