Message-ID: <CAGTjWtAo8dE4ASWYPZ0QJdNg3jFzpO=QP4eT5P3mNakxKy-5+g@mail.gmail.com>
Date:	Fri, 15 Jul 2011 11:13:04 -0700
From:	Mike Waychison <mikew@...gle.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Greg Kroah-Hartman <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Klibc mailing list <klibc@...or.com>,
	Andrew Morgan <agm@...gle.com>
Subject: Re: [PATCH 2/2] x86: Allow disabling of sys_iopl, sys_ioperm

On Thu, Jul 14, 2011 at 5:48 PM, Mike Waychison <mikew@...gle.com> wrote:
> On Thu, Jul 14, 2011 at 4:39 PM, Alan Cox <alan@...rguk.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)?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists