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? > > 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. > > 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.. > > 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). > > bye, > Sumit > _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
