Re: filesystem capabilities

[Steve Grubb <sgrubb () redhat com>]

> And to make things complete we not only have to deal with
> libcap (which I personally prefer even if its "more complex to use"),
> we also have cap-ng (http://people.redhat.com/sgrubb/libcap-ng)
> where a first look at the provided ping etc patches shows me
> that again the return values are not checked for
> capng_apply().

This was a quick example to show the usage. But the libcap-ng library was meant to 
stop people from doing capabilities tests like this:

if (!getuid()) {
    I am root, I must have privs
}

Instead, you can do:

if (capng_have_capabilities(CAPNG_SELECT_CAPS) > CAPNG_NONE) {
  I have some privs
}

We have run across problems caused by people doing test #1. I think libnet was a 
classic example.



> (My fault if it does and I overlooked it) And the whole cap/priv framework must
> *always and always* check return values as shown a dozens of times that
> this gives cool root exploits.

Sure.

> And I dont want to mention the semantics change between
> the kernel versions (2.6.25 etc).

That was also the second inspiration for libcap-ng. We now have a per task bounding 
set instead of system wide. What this means is that if you have an application that 
has been good enough to drop privs and is still running as uid 0, then all an attacker 
has to do is get the app to call execve and you have all privs back again. Prior to 
2.6.25, if you drop privs and you are uid 0, the privs stayed gone.

In the new world, you have to drop the bounding set to get the old behavior. This is 
done by using prctl. And being that there are 33 capabilities, you have to call prctl 
33 times. So, I figured it would be much better to wrap this up into a flag so that you 
can just "or" that into the set you want to operate on.

-Steve