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
> 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.
> 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
> 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
> 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
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.
> 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).
> 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
you are right, I just remembered someone saying the pam_unix will only
work when called by root, but this might be outdated.
sssd-devel mailing list