linux-kernel - Re: [PATCH 00/12] One more attempt at useful kernel lockdown

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: <1378781715.17982.42.camel@x230.lan>
Date:	Tue, 10 Sep 2013 02:55:15 +0000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	David Lang <david@...g.hm>
CC:	"Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 00/12] One more attempt at useful kernel lockdown

On Mon, 2013-09-09 at 19:44 -0700, David Lang wrote:
> On Tue, 10 Sep 2013, Matthew Garrett wrote:
> > No. Say someone adds an additional lockdown bit to forbid raw access to
> > mounted block devices. The "Turn everything off" approach now means that
> > I won't be able to perform raw access to mounted block devices, even if
> > that's something that my use case relies on.
> 
> I was meaning that if you only turn off features that you know about, the 
> addition of a new thing that can be disabled doesn't make you any worse off than 
> you were.

Someone adds a new "install_evil()" syscall and adds a disable bit. If I
don't disable it, I'm now vulnerable. Please pay attention to earlier
discussion.

> >> so if you only have a single bit, how do you deal with the case where that bit
> >> locks down something that's required? (your reason for not just setting all bits
> >> in the first approach)
> >
> > Because that bit is well-defined, and if anything is added to it that
> > doesn't match that definition then it's a bug.
> 
> it may be well defined, but that doesn't mean that it actually matches what the 
> system owner wants to do.

If it doesn't match what the system owner wants to do, the system owner
doesn't set it. The system owner uses a more appropriate security
mechanism instead.

> The idea that the programmer can possibly anticipate all possible needs and 
> provide a switch for exactly that need is just wrong. Users will have needs that 
> you never thought of. The best systems are the ones where the creators look at 
> what users are doing and react with "I never imagined doing that"

Describe the security case for disabling PCI BAR access but permitting
i/o port access.

> > Anything more granular means that you trust your userspace, and if you
> > trust your userspace then you can already set up a granular policy using
> > the existing tools for that job. So just use the existing tools.
> 
> If you can't trust your userspace, how do you know that the userspace has set 
> the big hammer flag in the first place? if you can trust it to throw that 
> switch, you can trust it to throw multiple smaller switches.

Hence the final patch in the series, and hence also the suggestion for
exposing it as a command line option that can be set by the bootloader
during an attested boot.

> >> And if SELinux can do the job, what is the reason for creating this new option?
> >
> > Because you can't embed an unmodifiable selinux policy in the kernel.
> 
> Why not, have the policy set in an initramfs that's part of the kernel and have 
> part of that policy be to block all access to the selinux controls.

Because then someone disables selinux on the kernel command line.

-- 
Matthew Garrett <matthew.garrett@...ula.com>