Re: [PATCH 2/2] x86: Allow disabling of sys_iopl, sys_ioperm

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> 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 ?