With CONFIG_SECURITY_FILE_CAPABILITIES=n, a task with CAP_SETPCAP can
grant capabilities from its permitted set to any other process id, or
remove them.
This means that a local attacker can attack any vulnerable root-owned
service and coerce it into giving its permitted capabilities to the
attacker.
If you wanted to verify that with a testcase, easiest thing is probably
just to write a program that does something like
int main(int argc, char *argv[])
{
pid = atoi(argv[1]);
cap_t mycaps = cap_from_text("all=p");
capsetp(pid, mycaps);
cap_free(mycaps);
}
(untested and uncompiled). Start one root and one non-root shell, and
from the root shell run the above with the process id of the non-root
shell, then cat /proc/self/status from the non-root shell and look at
your caps.
But I'm not clear on what you're trying to prove. Basically all I want is to
have CONFIG_SECURITY_FILE_CAPABILITIES=y in my default hardy kernel. Are you
trying to prove to yourself that that is safe? If you're trying to do a
detailed review of the security
decisions with the file capabilities, there are other things to consider as
well...
--
ubuntu kernel removes CAP_SETPCAP
https://bugs.launchpad.net/bugs/95089
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
