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 foraccessing block devices directly, but this doesn't seem to be thecase.

I think the approach I'll try next is to try and drop it withPR_CAPBSET_DROP from early userspace's init.