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