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