On Wed, Jul 23, 2014 at 06:39:40PM +0200, Sumit Bose wrote:
On Wed, Jul 23, 2014 at 06:21:06PM +0200, Jakub Hrozek wrote:
> On Wed, Jul 23, 2014 at 04:47:58PM +0200, Sumit Bose wrote:
> > On Wed, Jul 23, 2014 at 03:38:13PM +0200, Jakub Hrozek wrote:
> > > Hi,
> > >
> > > we'd like the SSSD in 1.12.1 to run as a non-privileged user. To
> > > summarize the discussions we had, I created the following design page:
> > >
https://fedorahosted.org/sssd/wiki/DesignDocs/NotRootSSSD
> > >
> > > For your convenience, the text of the page is also included below.
> > >
> > > I'll be glad for comments and another round of discussion.
> > >
> > > = Running SSSD as a non-root user =
> > >
> > > Related ticket(s):
> > > *
https://fedorahosted.org/sssd/ticket/2370
> > >
> > > === Problem statement ===
> > > Currently, all SSSD processes run as the root user. However, if one of the
processes was compromised, this might lead to compromising the whole system, especially if
additional measures like SELinux were not enabled. It would improve security if instead
SSSD was running as its own private user, This design page summarizes what would be needed
to run sssd as a non-privileged user and all the cases that currently require a root
user.
> >
> > Thank you Jakub for setting up this page and collecting all the details.
> >
> > I have a couple of general comments which you might want to put on this
> > page or can be added to a 'Running SSSD as a non-root user - Step 2'
> > page later. As a first step we should try to make SSSD able to run as
> > unprivileged user but do not do it by default. This means that e.g. we
> > do not change the permissions of the host keytab but describe on a wiki
> > page what has to be done to run SSSD as non-root user. Additionally this
> > page will be our task list about which setuid helpers are still needed
> > or which permission have to be set during installation.
>
> So you think the default for F-21 and RHEL-7.1 should still be root
> user? Or are you describing a first step in development?
If you think it would be possible in the given time-frame it would be
great to run as non-root user by default. But I think being able to run
as non-root user in most of the use-cases is a sufficiently high goal.
Yeah, unfortunately maintenance is taking most of the time :-/
That brings one question -- should the user to run as be configurable
during runtime, too? 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.
>
> >
> > 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.
>
> >
> > 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.
>
> >
> > A helper for accessing the
> > host keytab would be nice as well. But I think we need a bit of
> > additional support in libkrb5 for this. There already is a MEMORY keytab
> > type which can be used inside the unprivileged processes instead of the
> > FILE type. The helper can just read the content of the and pass it back
> > to the caller. But there is no libkrb5 call to pass a memory copy of the
keytab
> > file content into the related structs or into a MEMORY type keytab (at
> > least I haven't found a way so far). So the for the time being the host
> > keytab should be made available to the sssd user if SSSD should run
> > unprivileged.
>
> Ah, thanks, I remember you mentioned this earlier.
>
> >
> > About the sssd users. If SSSD can be started unprivileged the user
> > basically does not matter. We should only check in SSSD if the ownership
> > of the files and directories SSSD is using have save permissions, i.e.
> > belong to the user sssd is started as and have permissions set as you
> > described below. If SSSD stops or just logs a warning if some of the
> > permissions are unsafe can be configurable. Distributions most certainly
> > will create a special user for SSSD as upstream we should only make
> > sure that it is possible the 'make install' creates files and
> > directories with a configurable owner other than root where needed.
>
> Is this a common practice? In some of the deamons I checked (chrony,
> 389-ds) the Makefile.am installed files always as root and the files
> were owned by the user only in the specfile..
ah, ok, then it is even easier.
I will double check what is the best practice on other lists, too.
>
> >
> > 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.
Thank you for the review of the design page!