Comment 12 for bug 95089

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...