On Sat, 1 Nov 2014 17:29:47 +0100 Jakub Hrozek <[email protected]> wrote:
> 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? We can wait indeed. +1 to defer it. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
