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

Jakub Hrozek jhrozek at redhat.com
Mon Jul 28 11:17:50 UTC 2014


On Mon, Jul 28, 2014 at 06:29:39AM -0400, Simo Sorce wrote:
> On Wed, 2014-07-23 at 20:52 +0200, Jakub Hrozek wrote:
> > On Wed, Jul 23, 2014 at 06:39:40PM +0200, Sumit Bose wrote:
> 
> > Yeah, unfortunately maintenance is taking most of the time :-/
> > 
> > That brings one question -- should the user to run as be configurable
> > during runtime, too?
> 
> I'd prefer this, I see no reason to hardcode it at build time.
> 
> > Most deamons allow this and perhaps being able to
> > specify something like:
> > 
> > [sssd]
> > user = sssd
> > group = sssd
> > 
> > or conversely:
> > 
> > [sssd]
> > user = root
> > group = root
> > 
> > Might be a good way to have a workaround if we missed some corner case
> > that doesn't work with unprivileged process. Then, after we are
> > confident that all use cases work fine we could "just" flip the
> > defaults.
> 
> Sounds a good cautious approach, and allows users to flip back to root,
> should some corner case fail still.
> 
> > > 
> > > > 
> > > > > 
> > > > > We should try to be more ambitious here and say that SSSD can be started
> > > > > as unprivileged user i.e. none of the long running daemons run as root
> > > > > at any time. systemd offer option like User= and Group= start start
> > > > > daemons as any use, additionally it offers Capabilities= so the we can
> > > > > keep some capabilities, e.g. to send audit messages.
> > > > 
> > > > Yes, if the monitor can run as non-root, too. Currently I think the only
> > > > reason to run as root is to be able to spawn worker processes that start
> > > > as root.
> 
> We may need some capability to monitor interfaces/files ?
> 
> > > > > 
> > > > > Small and simple helper binary with setuid bit set will do any task that
> > > > > require root privileges like touching file like /etc/krb5.conf or
> > > > > changing the ownership of credential caches.
> > > > 
> > > > If we keep the backend as root after startup, then I would argue it's
> > > > easier to open krb5.conf as root and pass on a fd. If the backend starts
> > > > as the sssd user already, the yes, we need the setuid helper.
> > > 
> > > Yes, but it will still miss cases where krb5.conf is replaced  with a
> > > different version.
> > 
> > True. This sounds like a bit of a corner case, though.
> > 
> > In general, my concern is that any setuid binary raises a flag for
> > security teams in most distributions so I would prefer to keep their
> > number at a minimum. I guess if the binary did one thing only (like
> > touch /etc/krb5.conf here) and didn't accept any input, then it would be
> > easier to review for the security teams..I will try to gather some input
> > from the Fedora security team.
> 
> Why do we need to touch krb5.conf ?
> Isn't the version of libkrb5 we'll have in F21 going to have plugins for
> all the things we needed and we can stop including files in krb5.conf at
> runtime ?

Yes, but the same version might be used on RHEL-6 as well..I really
think RHEL-6 is a reasonable version to support upstream, Fedora is too
bleeding edge for many users.

However you do have a point, we can avoid touching /etc/krb5.conf when
possible.

> 
> > > 
> > > > 
> > > > > 
> > > > > Allow SSSD to run as the user as it is started would make testing easier
> > > > > as well because we can just start SSSD as the current user during make
> > > > > test (uid_wrapper would help here as well).
> > > > 
> > > > Sure!
> > > > 
> > > > > 
> > > > > About the PAM privileged pipe. I think we can remove it at least on
> > > > > platform where the SO_PEERCRED option for getsockopt() is available.
> > > > > With this we can reliable determine the UID of the caller, with the pipe
> > > > > in the private directory we depend on correctly set file system
> > > > > permissions. Maybe we can use the private pipe conditionally on
> > > > > platforms where SO_PEERCRED is not available (if any)?
> > > > > 
> > > > > About the proxy child. Some PAM modules, like e.g. pam_unix require root
> > > > > access, so I guess the proxy_child has to get a setuid bit.
> > > > 
> > > > Ah, I thought pam_unix had some setuid helper? But I haven't checked the
> > > > code (yet).
> > > 
> > > you are right, I just remembered someone saying the pam_unix will only
> > > work when called by root, but this might be outdated.
> > 
> > This is something we should double check with the PAM maintainer.
> 
> pam_unix does use a setuid helper, it is necessary for the password
> change case. However exclusively password changes are allowed, any other
> operation is not.

OK, thank you, I admit I still haven't checked the details.

> 
> I would also like to make a point I do not like making the system keytab
> directly accessible to the sssd user.
> 
> There are only 2 cases when access to the keytab is needed.
> 1 is obtaining credentials to access LDAP servers using the host/
> identity
> 2 is verification of authentication requests.
> 
> Both can be performed by a helper. For (1) the helper creates a private
> ccache file, which will be good until credentials expire.

Do you propose the helper runs as root here?

> For (2) we need a root helper to write ccache files as users, so
> validation can be done in the same helper as part of authentication.
> This means running some code as root, but it is nothing that involves
> network communication, as the ticket validity is checked locally against
> the keytab directly.

I need to bring this up on one of our internal lists. One of the reasons
for doing this exercise is to avoid any libkrb5 code to be run as root. If
we were building a solution just for upstream, I would agree, but this is
something other groups wold consume and I would like to make sure whatever
we do us usable by others, or we risk doing the same work twice.. I will
CC you on that mail..



More information about the sssd-devel mailing list