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:
user = sssd
group = 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
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
> > >
> > > 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.
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/
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.
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.
Simo Sorce * Red Hat, Inc * New York