[SSSD] Design Discussion: Restricting domains per PAM service

Simo Sorce ssorce at redhat.com
Tue Sep 23 13:07:06 UTC 2014


On Tue, 23 Sep 2014 11:22:45 +0200
Jakub Hrozek <jhrozek at redhat.com> wrote:

> On Mon, Sep 22, 2014 at 05:13:32PM +0200, Jakub Hrozek wrote:
> > On Mon, Sep 22, 2014 at 03:58:50PM +0200, Jan Pazdziora wrote:
> > > On Mon, Sep 22, 2014 at 03:54:09PM +0200, Jakub Hrozek wrote:
> > > > 
> > > > > 
> > > > > Why eactly does the list of domains need to be protected by
> > > > > the list of uids?
> > > > 
> > > > Apparently the rest of the PAM data can be faked by the client.
> > > 
> > > How is that worse than the current situation when the client can
> > > pass "user at DOMAIN.THEY.SHOULD.NOT.KNOW.ABOUT" to pam_start?
> > 
> > It's not worse, but the options aim at hardening the situation :)
> > 
> > Currently, all processes are untrusted and all processes can access
> > whatever domain they want. With the proposed scheme, some UIDs can
> > be trusted to send PAM data because we know who that process is.
> > These processes can not only access all domains but also restrict
> > themeselves to a subset of domains.
> > 
> > What is an untrusted process allowed to do is controlled by
> > a new proposed pam_allowed_auth_domains parameter. If you want only
> > trusted processes to access DOMAIN.THEY.SHOULD.NOT.KNOW.ABOUT you
> > can set:
> > 
> > [sssd]
> > domains = public, DOMAIN.THEY.SHOULD.NOT.KNOW.ABOUT
> > 
> > [pam]
> > pam_trusted_users = apache
> > pam_allowed_auth_domains = public
> > 
> > and in /etc/pam.d/httpd:
> > pam_sss domains=DOMAIN.THEY.SHOULD.NOT.KNOW.ABOUT
> > 
> > Now the apache user is able to access
> > DOMAIN.THEY.SHOULD.NOT.KNOW.ABOUT and all other users are only able
> > to access the public domain.
> > 
> > Makes sense?
> 
> 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.


-- 
Simo Sorce * Red Hat, Inc * New York



More information about the sssd-devel mailing list