Re: [PATCH] System Wide Capability Bounding Set

[Andrew G. Morgan]

On Tue, Feb 1, 2011 at 1:26 PM, Serge E. Hallyn
<serge.hallyn@xxxxxxxxxxxxx> wrote:
> Quoting Eric Paris (eparis@xxxxxxxxxx):
>> What are we thinking?  Any suggestions how to do what we need other than
>>
>> global bounding such that  pP' = gbset & (fI | pI)
>
> That should be sufficient for what you want.
>
> I would however like to hear whether Andrew has had any other ideas
> given the broader picture.
>

I think I now see what you are after.

You want some sort of transient TCB that can lock all of the doors you
care to lock and then run the whole system in a partially crippled
sandbox.

I have some concerns about how you know you have truly locked down the
system and question the viability of a VM that doesn't virtualize IO
too, but presumably you have some way to protect the storage of the
kernel binary and initrd that cannot be overcome, and protections from
DMA etc. being used by the guest to to overwrite kernel memory.

In this case, I would like to suggest what you need is a user
configurable state for kernel threads to launch helper programs - a
kernel side equivalent to Sergey's wrapper idea.  I continue to
dislike the global bounding set idea, but I would support a base
credential set for this kthread launcher. I'd include pI, bset, and
securebits and uid as something your initrd could initialize away from
their default values for kernel launched helper binaries. I'd prefer
it if you allowed the regular capability convolution rules to apply
and propagate this bounding set for all kernel launched binaries, and
also add the relevant code to init to enforce your desired bounding
set for init parented processes.

This way you will both meet your current needs and also maintain
support for a capability managed 'raw' kernel experience with no
asynchronous capability manipulation system-wide.

Cheers

Andrew


>> Or an interface in which I can force things out of the bset and pI of
>> other tasks?  Possibly the interface could be specific to the "khelper"
>> thread?
>
> No no no no no :)
>
> thanks,
> -serge
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/