>> Capability bit defaults for an executable:
...
>> The fN value is the miNimum needed to correctly execute.
>> The fX value is the maXimum that this executable is trusted with.
>> These help protect against buggy software.
>>
>> The default values for fI, fE, and fX might be adjustable.
>>
>> Files also have fK, the "bits known to the setup tool". Anything not
>> found in fK will be determined from the default values above. This is
>> important, because newly defined bits may include normal user abilities
>> that were simply expected when the executable was marked. It also gives
>> developers the ability to safely split one bit into two bits.
>
> You lost me about what fK is suppose to be.
You need to set bits on an executable with some kind of tool. The options
known to that tool may be a subset of what a new kernel supports.
It is tempting to just let such bits be 0, but that would be wrong.
Imagine what would happen if we added CAP_FORK (process can fork),
and we gave the CAP_FORK ability to every user by default. Unmarked
executables would be able to fork, but older marked executables would
suddenly be unable to fork! They don't work anymore.
To avoid this problem, the capability marking tool records all the bits
that were known at the time. When the kernel executes a marked executable,
it can use default values for anything that is not in fK.
Obviously the kernel can limit the extra 1 bits to capabilities that
were once part of the basic unrestricted API.
IMHO, fK is critical. Without it, the capabilities are cast in stone.
We will never be able to add a CAP_NET_CONNECT without fK.
>> new_pP = fP | (fI & old_pI) | (old_pP & config_option_1 & fX);
>
> I don't like your extension because it doesn't mask with pI at the very
> least.
Why should it? The draft did not mask pI, except as I have above.
My extension allows optional compatibility. Use config_option_1 to
disable it if you want strong security like the draft provides.
> Your fX is basicly my fI, and your config_option_1 is my pI which I
> beleive the executible should decide upon.
Nope, that is changing variables all over the place.
> If an program doesn't want
> CAP_FOO to be inherited then it shouldn't include it in pI. That way a
> smart binary can call other semi-trusted binaries without permanently
> maiming itself in the process by decreasing it's pP.
If you don't want pP passed along, set config_option_1 to 0.
>> if((new_pP & fN) != fN) return -EPERM; >
>
> I agree with this used sparingly for legacy binaries can save you some
> grief-- however it should be used like fE for backwards compatibility
> only. Maybe the user just wanted to run `foo --version` or `bar --help`
> ;->
Maybe `bar --help` has a buffer overflow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/