linux-kernel - Re: [PATCH 2/2] x86: Allow disabling of sys_iopl, sys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110715003912.149dcedd@lxorguk.ukuu.org.uk>
Date:	Fri, 15 Jul 2011 00:39:12 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Mike Waychison <mikew@...gle.com>
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
Subject: Re: [PATCH 2/2] x86: Allow disabling of sys_iopl, sys_ioperm

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