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