5 ms·

Let's be clear here. This is about enabling Lockdown when UEFI Secure Boot is enabled by default. So the concern is essentially that binary distributions, whic

Let's be clear here. This is about enabling Lockdown when UEFI Secure Boot is enabled by default. So the concern is essentially that binary distributions, which are going to be responsible for kernel flags, may enable this, whether it is default in the default kernel config or not. As best as I can tell that is the crux of Linus' concerns. MJG suggesting that the kernel flag can be turned off, while true, is not a response which considers the defacto usage which may result.

mjg59 9y ago
It's something that users are guaranteed the ability to disable for all distro kernels.
- Arbalest 9y ago
  How so? Adding such an ability removes the security right? If someone can set kernel flags, they could just as easily set the lockdown flag. If the package maintainers provide a different kernel image, then you still have the next boot issue. The fact that the shim exists erases any real protection against this. Therefore the only real protection comes when you put your own keys in. In which case, once again, enable lock down in the kernel config. I imagine that is exactly something enterprise vendors would be looking at. In the process of writing this, I have come to the conclusion that consumer secure boot is meaningless while the shim exists. The Microsoft approval process is, as I believe you said many years ago, fairly simple anyway. A company telephone number and a fee, if we're looking at other serious malicious actors. I acknowledge I may be misunderstanding this, and that you've already been over most/all of these issues before. I don't mind if you feel a response is not necessary.
  - mjg59 9y ago
    > How so? Run sudo mokutil --disable-validation > Adding such an ability removes the security right? No, because the mechanism used for this requires proof that you have access to the console - a remote attacker can't do it. A local attacker could, but there's support for passwording it to prevent this (it's equivalent to passwording the firmware setup) > I acknowledge I may be misunderstanding this You are, but there's a huge amount of misinformation about this stuff out there that makes it hard to find the actual information, so it's not surprising :)
    - Arbalest 9y ago
      I forsee this as a step in many online guides on "how do I [x] on linux" Edit: Having thought about this some more, I think perhaps we can model this workaround after SELinux. Sure, there were trivial cases (my wine game mmaps 0x0 and now doesn't work, after wunderbar emporium), but more often it was something like "My apache can't read my directory" "Just run setenforce 0 and try again" which then, rather than being followed up with audit2allow, usually results in the search "How to disable SELinux permanently". The fundamental problem is that, and you've covered this ground plenty of times, Secure boot is not secure by default. We're not really affording much more security for the most vulnerable systems which is run by small time system administrators rather than large tech corporates. Sure it would be great if we could educate people to protect their chain of trust (and arguably the best solution), but instead what we have is something which hampers usability, and opens the door to people who plan to come around and barricade the door after you. So by tying in this security by default measure, we could arguably afford and even greater illusion of protection, which runs counter to the intent of extending the protection of secure boot. Anyone willing enough to protect their chain of trust explicitly is also going to be able to research the issue. The flip side is that SELinux was adopted anyway. If there aren't actually that many server use cases which require this work around, then: Protection, awesome. But unlike SELinux policy, Lockdown policy is baked into the kernel (right?). If there are any issues, there is only one solution: disable Kernel Lockdown, which might be achieved by disabling secure boot validation.
dingo_bat 9y ago
But as Linus said, kernel lockdown has nothing to do with secure boot. Both are separate things. Why tie them together by default? It's like "automatically burn CD" if a CD-R is inserted into the drive. I can burn a CD sometime later. Or I can insert a CD-R and play it, not burn it.
- Jasper_ 9y ago
  From the top: the goal of the lockdown mode is to prevent someone who has UID=0 ("root") in the kernel from being able to modify or tamper with it (ring0 / CPL0 access). This can be done through /dev/mem, kexec, or even by asking a PCI card or FireWire device to DMA into physical system memory. Basically, there are a lot of hooks to tamper with the kernel, and "lockdown" mode turns them off. Now, this only really makes sense if you are in some sort of trusted untampered environment already: if not, someone with root can stomp a new kernel in /boot/ which gives them a backdoor. So, lockdown without a trusted boot environment is security theater, since you can just take the long road anyway. Additionally, in a trusted boot environment, the lockdown flag is wanted. If not, "trusted boot" really isn't such: someone that booted through a signed kernel can simply tamper with the kernel anyway after booting up through an init hook. The dangerous part: once they have the ability to tamper with the kernel, they can chainload another operating system and functional as a poisonous bootloader. The danger here is that if an attack like this is seen in the wild, and the attacker used, say, Fedora's kernel signing keys to do the attack, it has the possibility to get Fedora's keys blacklisted by OEMs. Linux would do best not to be used by an attacker as a "malware bootloader". That means it's reasonable for, by default, lockdown to be informed by the presence of a trusted boot environment.
  - Doxin 9y ago
    Presumably in that case you'd also want the kernel to fail loudly when it isn't booting securely. Say you enable lockdown but somehow manage to misconfigure secure boot, You'd much rather have the kernel go "oh whoops I've got lockdown enabled but I wasn't booted securely" than to boot the kernel insecurely without notice. And just like that it stops being a magically enabled thing and becomes something you have to either have fully on or fully off.

mjg59 9y ago

It's something that users are guaranteed the ability to disable for all distro kernels.

Arbalest 9y ago
How so? Adding such an ability removes the security right? If someone can set kernel flags, they could just as easily set the lockdown flag. If the package maintainers provide a different kernel image, then you still have the next boot issue. The fact that the shim exists erases any real protection against this. Therefore the only real protection comes when you put your own keys in. In which case, once again, enable lock down in the kernel config. I imagine that is exactly something enterprise vendors would be looking at. In the process of writing this, I have come to the conclusion that consumer secure boot is meaningless while the shim exists. The Microsoft approval process is, as I believe you said many years ago, fairly simple anyway. A company telephone number and a fee, if we're looking at other serious malicious actors. I acknowledge I may be misunderstanding this, and that you've already been over most/all of these issues before. I don't mind if you feel a response is not necessary.
- mjg59 9y ago
  > How so? Run sudo mokutil --disable-validation > Adding such an ability removes the security right? No, because the mechanism used for this requires proof that you have access to the console - a remote attacker can't do it. A local attacker could, but there's support for passwording it to prevent this (it's equivalent to passwording the firmware setup) > I acknowledge I may be misunderstanding this You are, but there's a huge amount of misinformation about this stuff out there that makes it hard to find the actual information, so it's not surprising :)
  - Arbalest 9y ago
    I forsee this as a step in many online guides on "how do I [x] on linux" Edit: Having thought about this some more, I think perhaps we can model this workaround after SELinux. Sure, there were trivial cases (my wine game mmaps 0x0 and now doesn't work, after wunderbar emporium), but more often it was something like "My apache can't read my directory" "Just run setenforce 0 and try again" which then, rather than being followed up with audit2allow, usually results in the search "How to disable SELinux permanently". The fundamental problem is that, and you've covered this ground plenty of times, Secure boot is not secure by default. We're not really affording much more security for the most vulnerable systems which is run by small time system administrators rather than large tech corporates. Sure it would be great if we could educate people to protect their chain of trust (and arguably the best solution), but instead what we have is something which hampers usability, and opens the door to people who plan to come around and barricade the door after you. So by tying in this security by default measure, we could arguably afford and even greater illusion of protection, which runs counter to the intent of extending the protection of secure boot. Anyone willing enough to protect their chain of trust explicitly is also going to be able to research the issue. The flip side is that SELinux was adopted anyway. If there aren't actually that many server use cases which require this work around, then: Protection, awesome. But unlike SELinux policy, Lockdown policy is baked into the kernel (right?). If there are any issues, there is only one solution: disable Kernel Lockdown, which might be achieved by disabling secure boot validation.

dingo_bat 9y ago

But as Linus said, kernel lockdown has nothing to do with secure boot. Both are separate things. Why tie them together by default? It's like "automatically burn CD" if a CD-R is inserted into the drive. I can burn a CD sometime later. Or I can insert a CD-R and play it, not burn it.

Jasper_ 9y ago
From the top: the goal of the lockdown mode is to prevent someone who has UID=0 ("root") in the kernel from being able to modify or tamper with it (ring0 / CPL0 access). This can be done through /dev/mem, kexec, or even by asking a PCI card or FireWire device to DMA into physical system memory. Basically, there are a lot of hooks to tamper with the kernel, and "lockdown" mode turns them off. Now, this only really makes sense if you are in some sort of trusted untampered environment already: if not, someone with root can stomp a new kernel in /boot/ which gives them a backdoor. So, lockdown without a trusted boot environment is security theater, since you can just take the long road anyway. Additionally, in a trusted boot environment, the lockdown flag is wanted. If not, "trusted boot" really isn't such: someone that booted through a signed kernel can simply tamper with the kernel anyway after booting up through an init hook. The dangerous part: once they have the ability to tamper with the kernel, they can chainload another operating system and functional as a poisonous bootloader. The danger here is that if an attack like this is seen in the wild, and the attacker used, say, Fedora's kernel signing keys to do the attack, it has the possibility to get Fedora's keys blacklisted by OEMs. Linux would do best not to be used by an attacker as a "malware bootloader". That means it's reasonable for, by default, lockdown to be informed by the presence of a trusted boot environment.
- Doxin 9y ago
  Presumably in that case you'd also want the kernel to fail loudly when it isn't booting securely. Say you enable lockdown but somehow manage to misconfigure secure boot, You'd much rather have the kernel go "oh whoops I've got lockdown enabled but I wasn't booted securely" than to boot the kernel insecurely without notice. And just like that it stops being a magically enabled thing and becomes something you have to either have fully on or fully off.