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

[Matthew Garrett <matthew.garrett@nebula.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2923 bytes --]

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@nebula.com>
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥