Re: [PATCH] System Wide Capability Bounding Set

[Eric Paris <eparis@redhat.com>]

On Sun, 2011-01-16 at 19:16 -0800, Andrew G. Morgan wrote:

> I'm not a supporter of system-wide security contexts changing under
> running programs. Previous experience has taught me that tricking a
> program into thinking it has one sort of privilege and then
> withdrawing it without notice can be dangerous.

But a bounding set doesn't affect a running program's abilities, the
bset is only applied at exec().  So if it's fcaps based you have all
that wacky kill logic.

>  Since privileged
> programs include shells that invoke privileged commands to perform
> system admin tasks, I consider a global bounding set to be trouble in
> the making. 

No question, but then again, if you have CAP_SYS_MODULE there are a lot
easier ways to make trouble   :)

> If we were to delete that special code what I think is missing from
> the current kernel model, is not a global bounding set, but a 'kernel
> auto-exec' securebits value. One that can be set by an admin at
> runtime to suppress the root-is-all-capable behavior of the auto-exec
> process, and defer the privilege escalation to carefully audited file
> capabilities on the relevant helper binaries.

But how can that leave us with an impotent root?  Root would be easily
able to craft a file with any caps it wants in fI and fP on any of the
plethora of helper programs the kernel calls and escalate away it's
impotence.

I'd really like to drop a cap from an entire system never to return.
Maybe I can get there by exposing the bset of the kthread which launches
the helpers (makes me feel very dirty).  But that is smaller than the
global bset....

-Eric