6 ms·

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

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.
  - Jasper_ 9y ago
    One would hope your system would complain loudly in the BIOS if Secure Boot wasn't on regardless of the operating system. If some malware manages to misconfigure Secure Boot, it can also patch your kernel to remove the complaining.
  - mjg59 9y ago
    The kernel isn't able to determine whether you booted in a verifiable manner in all cases, so there's functionality that allows the bootloader to make that decision rather than the kernel. But if you don't have a verified boot environment and someone is deliberately attacking you, it's easy for them to fake up your early boot environment such that the kernel believes it's booted securely even if it hasn't been. If you want to protect against accidents then you can do that in userspace. There's no need for the kernel to be involved.
- pensativo 9y ago
  This is what @mjg95 should be saying.
  - mjg59 9y ago
    This is literally what I have been saying
    - pensativo 9y ago
      Apologies, that wasn't relayed to me in what I've read so far. Good luck.
- tjoff 9y ago
  Wait, all these are protections are useless because someone with root can defeat them? Huh? These protections should vastly reduce the risks of someone gaining root and make it much harder to do so to a running system with physical access. Or? Seems to me that it is just as much security theater to pretend that it isn't game over if someone already has root. edit: and perhaps the (by far?) biggest benefit of lockdown is to make it harder for someone to gain root?
  - Jasper_ 9y ago
    "root user" is a term that we choose to mean what we want it to. Some people in the Linux community want to restrict the root user / cap_sys_admin so that even them cannot tamper with a secure kernel or run ring0 code under certain configurations. I think this is a great idea.
  - mjg59 9y ago
    There's a kernel-imposed boundary between being a user and being root. Right now there's also a partial barrier between being root and being the kernel that's fairly easily circumvented. Now that we can protect the on-disk copy of the kernel from root, there's also interest in protecting the in-memory copy of the kernel from root.
    - tjoff 9y ago
      Yes. And lockdown helps with (right?): a) locking root out of kernel b) locking users from becoming root I interpret the reasoning as: if we can't do a AND b we won't bother with b. Which is confusing because b is many orders of magnitudes more important than a.
      - mjg59 9y ago
        b) is a barrier that's already supposed to exist, so these patches don't have an impact on it.
        tjoff 9y ago
- dingo_bat 9y ago
  > 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) Exactly, and that's why lockdown and secure boot must be discarded. These are attempts to take control away from the user and give it to the OS maker or device manufacturer. This is exactly why I cannot root my android without losing hardware features and this is exactly why ios devices are not general purpose computers. Fuck these anti-user efforts. They have no place in Linux.
  - mjg59 9y ago
    All Linux distributions that support UEFI secure boot allow you to disable any restrictions if you have physical access to the machine. If you have a device vendor who's implemented something more restrictive, blame the device vendor rather than the software.
    - throwaway2048 9y ago
      or blame the FLOSS people working so hard to enable them.
  - viraptor 9y ago
    This is only anti-user from one point of view (where jailbreaking is beneficial). It's completely pro-user, where the user wants to ensure that the environment is what they expect it to be. It really depends on who the user is and what they want to achieve. Otherwise you could describe something like process memory protection the same way: not being able to read/write directly to a root process is taking the control away from the user after all.
  - teknopaul 9y ago
    I second this. I use linux because i want root. Linux needs users to be kernel devs. If hardware vendors want to lock down kernels let them patch in the lockdown.
  - shawnz 9y ago
    > this is exactly why ios devices are not general purpose computers. What general purpose computation requires root?
- caf 9y ago
  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. Here's the bit I don't get: even if you can't be used as a chainloading malware bootloader, can't you still be used as a slightly more complicated malware bootloader that fires up the victim OS under virtualisation?
  - gruez 9y ago
    under secureboot, you would need to get that boot loader signed
    - caf 9y ago
      But you are signed - you're a vanilla distro kernel booting a custom userspace that fires up the victim OS under virtualisation.
      - Jasper_ 9y ago
        You're suggesting a construction like Blue Pill[0], right, where you have a "malware hypervisor"? The concept is known, security people are aware, it's considered moderately infeasible, and multiple techniques can prevent it[1]. [0] https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software) [1] http://northsecuritylabs.blogspot.com/2008/06/catching-blue-pill.html http://northsecuritylabs.blogspot.com/2008/06/catching-blue-...
        caf 9y ago
        That mitigation technique relies on the anti-malware executable starting before the malware does.

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.
- Jasper_ 9y ago
  One would hope your system would complain loudly in the BIOS if Secure Boot wasn't on regardless of the operating system. If some malware manages to misconfigure Secure Boot, it can also patch your kernel to remove the complaining.
- mjg59 9y ago
  The kernel isn't able to determine whether you booted in a verifiable manner in all cases, so there's functionality that allows the bootloader to make that decision rather than the kernel. But if you don't have a verified boot environment and someone is deliberately attacking you, it's easy for them to fake up your early boot environment such that the kernel believes it's booted securely even if it hasn't been. If you want to protect against accidents then you can do that in userspace. There's no need for the kernel to be involved.
pensativo 9y ago
This is what @mjg95 should be saying.
- mjg59 9y ago
  This is literally what I have been saying
  - pensativo 9y ago
    Apologies, that wasn't relayed to me in what I've read so far. Good luck.
tjoff 9y ago
Wait, all these are protections are useless because someone with root can defeat them? Huh? These protections should vastly reduce the risks of someone gaining root and make it much harder to do so to a running system with physical access. Or? Seems to me that it is just as much security theater to pretend that it isn't game over if someone already has root. edit: and perhaps the (by far?) biggest benefit of lockdown is to make it harder for someone to gain root?
- Jasper_ 9y ago
  "root user" is a term that we choose to mean what we want it to. Some people in the Linux community want to restrict the root user / cap_sys_admin so that even them cannot tamper with a secure kernel or run ring0 code under certain configurations. I think this is a great idea.
- mjg59 9y ago
  There's a kernel-imposed boundary between being a user and being root. Right now there's also a partial barrier between being root and being the kernel that's fairly easily circumvented. Now that we can protect the on-disk copy of the kernel from root, there's also interest in protecting the in-memory copy of the kernel from root.
  - tjoff 9y ago
    Yes. And lockdown helps with (right?): a) locking root out of kernel b) locking users from becoming root I interpret the reasoning as: if we can't do a AND b we won't bother with b. Which is confusing because b is many orders of magnitudes more important than a.
    - mjg59 9y ago
      b) is a barrier that's already supposed to exist, so these patches don't have an impact on it.
      - tjoff 9y ago
dingo_bat 9y ago
> 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) Exactly, and that's why lockdown and secure boot must be discarded. These are attempts to take control away from the user and give it to the OS maker or device manufacturer. This is exactly why I cannot root my android without losing hardware features and this is exactly why ios devices are not general purpose computers. Fuck these anti-user efforts. They have no place in Linux.
- mjg59 9y ago
  All Linux distributions that support UEFI secure boot allow you to disable any restrictions if you have physical access to the machine. If you have a device vendor who's implemented something more restrictive, blame the device vendor rather than the software.
  - throwaway2048 9y ago
    or blame the FLOSS people working so hard to enable them.
- viraptor 9y ago
  This is only anti-user from one point of view (where jailbreaking is beneficial). It's completely pro-user, where the user wants to ensure that the environment is what they expect it to be. It really depends on who the user is and what they want to achieve. Otherwise you could describe something like process memory protection the same way: not being able to read/write directly to a root process is taking the control away from the user after all.
- teknopaul 9y ago
  I second this. I use linux because i want root. Linux needs users to be kernel devs. If hardware vendors want to lock down kernels let them patch in the lockdown.
- shawnz 9y ago
  > this is exactly why ios devices are not general purpose computers. What general purpose computation requires root?
caf 9y ago
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. Here's the bit I don't get: even if you can't be used as a chainloading malware bootloader, can't you still be used as a slightly more complicated malware bootloader that fires up the victim OS under virtualisation?
- gruez 9y ago
  under secureboot, you would need to get that boot loader signed
  - caf 9y ago
    But you are signed - you're a vanilla distro kernel booting a custom userspace that fires up the victim OS under virtualisation.
    - Jasper_ 9y ago
      You're suggesting a construction like Blue Pill[0], right, where you have a "malware hypervisor"? The concept is known, security people are aware, it's considered moderately infeasible, and multiple techniques can prevent it[1]. [0] https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software) [1] http://northsecuritylabs.blogspot.com/2008/06/catching-blue-pill.html http://northsecuritylabs.blogspot.com/2008/06/catching-blue-...
      - caf 9y ago
        That mitigation technique relies on the anti-malware executable starting before the malware does.