On Sat, 1 Nov 2014 17:29:47 +0100
Jakub Hrozek <jhrozek(a)redhat.com> 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
> > [http://cwrap.org/nss_wrapper.html
nss_wrapper] are the best choice.
> 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:
> 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.
We can wait indeed.
+1 to defer it.