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.