[SSSD] Design discussion: SSSD running as a non-root user

Simo Sorce ssorce at redhat.com
Mon Oct 13 21:19:20 UTC 2014


On Mon, 13 Oct 2014 17:59:45 +0200
Jakub Hrozek <jhrozek at redhat.com> wrote:

> On Wed, Jul 23, 2014 at 03:38:13PM +0200, Jakub Hrozek wrote:
> > ==== PAM responder ====
> > The PAM responder can drop privileges after startup. The files that
> > the PAM responder reads (sysdb, confdb, PAM public pipe) and writes
> > (debug logs, PAM pipe) will be owned by the sssd user.
> > 
> > In order to keep the privileged pipe only owned by the root user, we
> > would open the pipe prior to becoming user and pass the file
> > descriptor.
> 
> As we're testing the patches with Michal, we realized one thing that
> I didn't check when creating the design.
> 
> The pam_sss.so module explicitly checks if the PAM pipe (private or
> not) is owned by UID 0. Because we initially wanted to let the
> non-private PAM pipe be owned by the SSSD user, this check fails.
> Please note the public pipe has permissions 0666, so the ownership
> doesn't matter that much, 'others' are always allowed to read and
> write to the pipe.
> 
> So we have two options:
>     1) Let the public PAM pipe be owned by root and create it prior to
>     dropping privileges
>         + No changes to the client code
>         - a bit messy responder initialization where the PAM responder
>           would create both pipes itself. All other responders could
>           still rely on the shared setup code.

I'd prefer 1, it insures the pipe can only be created by a high
privileged process so no takeover is possible.

>     2) Extend the check in the PAM module so that both UID 0 and UID
> of the SSSD user are allowed.
>         + Nicer responder code
>         - Touches client code. Please note that I'm not sure if PAM
>           modules are loaded on every PAM conversation or not. If they
>           stay loaded for the duration of the application (like the
> NSS module), then this option is not viable at all.

Pam modules are reloaded at each use, but you do not know how long an
authentication take, I am not sure what happens with login applications
that sit there for a long time awaiting for input from a terminal.

Simo.

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



More information about the sssd-devel mailing list