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
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
nss_wrapper] are the best choice.
this is another aspect of the original design that I'm no longer sure
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.
Simo Sorce * Red Hat, Inc * New York