Messages in this thread | | | From | Mike Waychison <> | Date | Thu, 14 Jul 2011 17:48:48 -0700 | Subject | Re: [PATCH 2/2] x86: Allow disabling of sys_iopl, sys_ioperm |
| |
On Thu, Jul 14, 2011 at 4:39 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: >> In my case, I simply don't want these "features", which is why I took >> the compile time approach to turning this stuff off. I realize that >> these syscalls (and the /dev/port interface) are not comprehensive (I >> didn't say they were either). I'm happy though to take suggestions > > Indeed - but from the point of view of doing the job to a standard for > an upstream kernel there ought to be a meaningful testable definition of > what the security shift you achieve is. > >> 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.
Any other vectors you would suggest to keep the kiddies away? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |