On Mon, 13 Oct 2014 17:59:45 +0200 Jakub Hrozek <[email protected]> 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 _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
