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:
> 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:
> 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?
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.
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..
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