[SSSD] Design discussion: SSSD running as a non-root user

Jakub Hrozek jhrozek at redhat.com
Sat Nov 1 16:29:47 UTC 2014


On Wed, Jul 23, 2014 at 03:38:13PM +0200, Jakub Hrozek wrote:
> === Using libcap-ng to drop the privileges ===
> Even though we already have some code to drop privileges in the `krb5`provider, we should leverage the [https://people.redhat.com/sgrubb/libcap-ng/ libcap-ng] project for privilege drop. The added benefits over doing the privilege drop ourselves are:
>  * libcap-ng is tested and used by many other packages already. For security-sensitive code, it's advisable to re-use existing code rather than hit the same mistakes someone else did already.
>  * libcap-ng also allows to work with capabilities. For some cases, this might be beneficial in future, for instance, we might need to retain the auditing capability.
> 
> The downside is obviously the extra dependency, but libcap-ng has a small footprint and is already used by packages that are present on most, if not all, modern Linux installations, such as dbus.
> 
> We should keep the existing code around as a fallback for environments that don't have the libcap-ngs library available, such as non-Linux systems or embedded systems. Because the code wouldn't be enabled by default, it's important to have unit tests for the privilege drop. For unit testing both options (libcap-ng and our own code), [http://cwrap.org/uid_wrapper.html uid_wrapper] and [http://cwrap.org/nss_wrapper.html nss_wrapper] are the best choice.

Hi,

this is another aspect of the original design that I'm no longer sure is
valid.

I have prepared the patches that use libcap-ng by default:
    https://fedorapeople.org/cgit/jhrozek/public_git/sssd.git/commit/?h=nonroot-libcap&id=eadfbd97c9fbf9beb7c6b358e44e0e1e4a5628ae

But I'm not sure we need to merge them at this point, because:
    1) Since uid_wrapper doesn't support faking capabilities (yet!),
    it's hard to unit test the uid dropping using libcap-ng
    2) We actually don't use capabilities (again..yet, maybe we'll use
    CAP_AUDIT_WRITE in the future)

So the only advantage we'd gain is that code that drops privileges could
be offloaded to libcap that is used and tested by other projects, too.
But given that we'd keep our code around, too, for minimal environments
(we have users running sssd on embedded systems where every extra
dependency counts..) I'm not convinced there is too much value in
merging the libcap-ng support now.

Thoughts?



More information about the sssd-devel mailing list