klibc - Jul 2011 - [PATCH 2/2] x86: Allow disabling of sys_iopl, sys_ioperm

On Thu, Jul 14, 2011 at 5:48 PM, Mike Waychison <mikew at google.com>
wrote:
> On Thu, Jul 14, 2011 at 4:39 PM, Alan Cox <alan at
lxorguk.ukuu.org.uk> wrote:
>>> for stuff I probably should be disabling considering my goal of
making
>>> it difficult for root to compromise a system. ?And yes, modules are
>>> disabled :)
>>
>> If you have CAP_SYS_RAWIO and some of the other interfaces you only
think
>> it is - the kiddies toolkits already include out of the box direct
module
>> loading hacks (in fact its fairly easy if you've got GPU PCI access
to
>> just put the module into video memory so that only the patching needs
to
>> be done and the module internal addresses are all fixed and can be
>> arranged on a suitably convenient target address)
>>
>> So really there needs to be a definition of what you are trying to
>> achieve. My own guess is that for
>>
>> ? ? ? ?"Disallow direct access paths to hardware"
>>
>> the actual answer is 'revoke RAWIO' and then give it back to
very
>> specific selected code in very specific selected ways or possibly in
some
>> cases where rawio is needed for stuff that shouldn't be by writing
new
>> driver bits to provide the proper interface that we are lacking ?
>>
>> So lets turn the question around a moment - what breaks if you simply
>> take CAP_SYS_RAWIO away from everything ?
>>
>
> Alright, I see your point. ? ISTR that CAP_SYS_RAWIO was required for
> accessing block devices directly, but this doesn't seem to be the
> case.
>
> I think the approach I'll try next is to try and drop it with
> PR_CAPBSET_DROP from early userspace's init.
>
For my use-case, I'd like to have a system boot with a non-default
bounding set of posix capabilities.  I'd like the system to *never* be
able to use these capabilities, so I'd like to drop them early on when
userland starts up.  Given this requirement (and the fact that
capability manipulation is process-local), I'd like for my init setup
to drop certain bits from the bounding set early on during bootup.

I'm thinking of adding the following linux command line flag:

capbset_drop=<comma separated list of capabilities>

example:

capbset_drop=CAP_SYS_RAWIO
capbset_drop=CAP_SYS_RAWIO,CAP_NET_RAW

I'm thinking that this option would drop the listed capabilities from
the bounding set, as well as init's permitted, effective and inherited
masks.

I'd probably want to eventually also provide a way to set the
securebits (they seem to operate in the same way?), though for now I'd
rather tackle the capability masks directly.

So the question is, should this go in the kernel proper such that it
manipulates the init_cred structure, or should this be plumbed down in
kinit (in klibc, which we use for bootup)?

On 07/15/2011 11:13 AM, Mike Waychison wrote:
> 
> So the question is, should this go in the kernel proper such that it
> manipulates the init_cred structure, or should this be plumbed down in
> kinit (in klibc, which we use for bootup)?
> 
It certainly would be trivial to do in kinit.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.