On Mon, 13 Oct 2014 17:59:45 +0200
Jakub Hrozek <jhrozek(a)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