On Thu, Mar 12, 2015 at 3:10 PM, Andrew G. Morgan <morgan@xxxxxxxxxx> wrote:
> I'm unclear why you refer to the inheritable set in this test:
>
> + } else {
> + if (arg2 == PR_CAP_AMBIENT_RAISE &&
> + (!cap_raised(current_cred()->cap_permitted, arg3) ||
> + !cap_raised(current_cred()->cap_inheritable,
> + arg3)))
> + return -EPERM;
It's to preserve the invariant that pA is always a subset of pI.
>
> I'm also unclear how you can turn off this new 'feature' for a process
> tree? As it is, the code creates an exploit path for a capable (pP !=
> 0) program with an exploitable flaw to create a privilege escalation
> for an arbitrary child program.
Huh? If you exploit the parent, you already win. Yes, if a kiddie
injects shellcode that does system("/bin/bash") into some pP != 0
program, they don't actually elevate their privileges. On the other
hand, by the time an attacker injected shellcode for:
prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, CAP_SYS_ADMIN);
system("/bin/bash");
into a target, they can already do whatever they want.
> While I understand that everyone
> 'knows what they are doing' in implementing this change, I'm convinced
> that folk that are up to no good also do... Why not provide a lockable
> secure bit to selectively disable this support?
Show me a legitimate use case and I'll gladly implement a secure bit.
In the mean time, I don't even believe that there's a legitimate use
for any of the other secure bits (except keepcaps, and I don't know
why that's a securebit in the first place).
In the mean time, see CVE-2014-3215 for an example of why securebits
are probably more trouble than they're worth.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
