On Tue, Apr 3, 2018 at 4:26 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett <mjg59@xxxxxxxxxx> wrote: > > > > 1) Secure Boot is intended to permit the construction of a boot chain that > > only runs ring 0 code that the user considers trustworthy > No. > That may be *one* intention, for some people. > It's not an a-priori one for the actual user. Secure Boot is intended to *permit* that. Without Secure Boot you're unable to do that. Some users want that. Some users don't. > > 2) Allowing arbitrary user code to run in ring 0 without affirmative > > consent on the part of the user is therefore incompatible with the goals of > > Secure Boot > Again, that has absolutely zero relevance. > Those goals are not the *users* goals. > Be honest now. It wasn't generally users who clamored for it. If you ask a user whether they want a system that lets an attacker replace their kernel or one that doesn't, what do you think their answer is likely to be? > If the user actually wanted it, and is asking for it, he can enable > it. Independently of secure boot, which the user generally has little > control over. How? If the bootloader will boot kernels that don't impose this restriction then an attacker just replaces whatever's enabling that feature. And, uh, seriously, I've been asking for *years* for someone to point me at a PC on the market that doesn't give the user control over Secure Boot, but Shim was expressly designed to ensure that the user would have the ability to enroll additional trusted keys (or disable signature validation entirely), so which cases are you thinking of where the user doesn't have control? > > 3) This patchset provides a mechanism to alter the behaviour of the kernel > > such that it is significantly more difficult for arbitrary user code to run > > in ring 0 without affirmative user consent > That difficulty already exists, the new thing isn't somehow related to > that at all. > Look at our "uyou can only load modules if you're root" rules. Or the > "you can only load modules if they are signed". > See a pattern there? They don't magically enable themselves (or > disable themselves) depending on whether you booted with secure boot > or not. What's the benefit of "You can only load modules if they are signed" if root is able to just overwrite that policy bit in the kernel? The split between unprivileged users and root is real, but right now module signatures are theater - there's no significant security benefit from them. But the reason to tie this to Secure Boot is that without that an attacker who has root can just replace the kernel on disk (or patch the bootloader to live-patch the kernel on boot, and yes that's an attack we've seen in the real world), so while it's a feature that is arguably beneficial under all circumstances it's a feature that only has significant benefit if you have some way to actually validate what you're booting in the first place. > > 4) Providing a mechanism for automatically enabling this behaviour when > > running in a context that is intended to restrict access to ring 0 is a > > rational thing to do, because otherwise it is difficult to achieve the > > objective in (1) > No. See why it's *NOT* rational, as explained already several times. > Magically changing kernel behavior depending on some subtle and often > unintentional bootup behavior detail is completely idiotic. > It would be idiotic if it was that "check kernel module signatures" > check. This is no less idiotic. > Seriously, listen to your own arguments. If they don't make sense for > checking kernel module signatures, why the hell would they make sense > for something like lockdown. > THE TWO THINGS ARE ENTIRELY INDEPENDENT. Again, what is your proposed mechanism for ensuring that off the shelf systems can be configured in a way that makes this possible? -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
