Mike Waychison
2011-Jul-15 18:13 UTC
[klibc] [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)?
H. Peter Anvin
2011-Jul-15 18:14 UTC
[klibc] [PATCH 2/2] x86: Allow disabling of sys_iopl, sys_ioperm
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.