10 ms·

Linux kernel lockdown, integrity, and confidentiality

142 points by JNRowe 7y ago

sandGorgon 7y ago
I think Fedora Silverblue takes a very different approach here - https://docs.fedoraproject.org/en-US/fedora-silverblue/ https://docs.fedoraproject.org/en-US/fedora-silverblue/ It basically doesn't try to fix the building blocks with all their legacy...instead it simply makes the entire operating system immutable. I wonder what are the pros and cons of each approach. Or are they complementary.
- jchw 7y ago
  Complementary. Silverblue’s immutability may be aimed purely at stability and therefore may not have strong guarantees, but if it did then the next attack vector would be from root to kernel (in memory), and that’s where lockdown comes in; it’s designed to prevent attacking a running kernel as root.
jasonhansel 7y ago
Another option might be to allow a "rootless" mode in which direct access to the root account itself is impossible (but where there are still ways for non-root users to gain a subset of root capabilities).
lwb 7y ago
Possibly a dumb question -- how can one perform kernel/firmware updates if root is "locked out"?
- Ao7bei3s 7y ago
  The integrity mode applies to the running kernel in RAM. You generally don't actually upgrade that, instead you replace the kernel image on disk (vmlinuz), which is still possible. On next boot, the new image will be loaded. But if you have trusted boot enabled, the new image will only be booted if it is appropriately signed. Live patching still works if the updates are signed. The kernel can still do whatever - with integrity enabled it just refuses to do certain things, such as loading kernel modules or updates that aren't signed.
  - lwb 7y ago
    Great explanation, thanks!
staticassertion 7y ago
Surprised no one has yet commented on eBPF, and the impact this has. ebpf already gives users the right to run code as the kernel, and this is a security win in many cases - you can audit your system better. On a server, I think I'd rather assume the attacker has root (or even kernel!) but have good auditing, and do specific service sandboxing, than assume that I can separate root from kernel. My understanding is that confidentiality breaks ebpf. I'm unsure about integrity - if integrity works with it, great. Then I'd wonder where you'd want confidentiality - maybe a box that's handling CC info/ payment processing? I have mixed feelings overall.
- mjg59 7y ago
  Integrity doesn't restrict ebpf. Confidentiality is for cases where you're doing stuff like using EVM to prevent offline attacks, which involves the kernel holding a key and using it to sign all files. This can be circumvented if you're able to just scrape the secret out of the kernel.
  - staticassertion 7y ago
    Cool, that sounds reasonable then. Good stuff.
freedomben 7y ago
This lockdown made it a huge PITA to run Wireguard in Fedora[1]. It broke existing installs when the kernel upgraded and then became very difficult to insmod or modprobe the wireguard kernel modules unless you blacklisted all new kernels (not safe). I hope this matures in a way that doesn't destroy some of the reasons I love Linux (that I can hack on my system and do cool stuff). [1] https://unix.stackexchange.com/q/543576/34855 https://unix.stackexchange.com/q/543576/34855
- htfy96 7y ago
  Wireguard is merged into the mainline and would possibly appear in Fedora 32 on 5.6. Fedora 32 will be released several weeks later. The underlying problem is that many distro just use a throwaway pubkey which makes users impossible to sign their modules. Maybe a better security model is needed.
  - freedomben 7y ago
    yeah for this reason I've been super excited for kernel 5.6 (I don't usually get excited for new kernel releases cause it means work for me, but this one is different :party: )
- jamielinux 7y ago
  You can sign modules using these instructions: https://docs.fedoraproject.org/en-US/fedora/f31/system-administrators-guide/kernel-module-driver-configuration/Working_with_Kernel_Modules/#sect-signing-kernel-modules-for-secure-boot https://docs.fedoraproject.org/en-US/fedora/f31/system-admin... Though it's definitely a faff, and it's required every time there's kernel upgrade.
stefan_ 7y ago
Do people realize what they are doing here? I'm happy not touching my Windows kernel, stuff generally just works. Stuff never just works on Linux. And now the last time I tried to load a kernel module I had built for my Ubuntu system, it refused because, duh, it wasn't signed by some UEFI key I had never even seen. So now of course, the Ubuntu is fucking gone. Because it makes it impossible to do things that on Linux are still a monthly requirement. Not to mention the impact this stuff has on kernel and driver development. Even Windows you can just boot into a development mode and it might scream at you on the desktop, but it will allow you to modify your system as you wish. I wasted a few hours when that Ubuntu thing happened to figure out where that switch was and didn't find it. Right now, this should be strictly the domain of Google and Amazon that can actually have a trusted chain from bootloader to userland. Not enabled on any vanilla Ubuntu because hey, we detected UEFI!
- segfaultbuserr 7y ago
  > And now the last time I tried to load a kernel module I had built for my Ubuntu system, it refused because, duh, it wasn't signed by some UEFI key I had never even seen. So now of course, the Ubuntu is fucking gone. There is no conspiracy here. The option you are looking for is in your BIOS/UEFI, not in the OS. You should have known better and read the fucking manual. Your machine comes with Secure Boot enabled by default, by the policy of Secure Boot, there are two possible outcomes. 1. If the OS doesn't support Secure Boot, you cannot boot the OS until Secure Boot is disabled (or you add your own signing key to BIOS/UEFI). 2. If the OS supports Secure Boot and signed by a big firm, you can boot it by default, but by the policy, it cannot execute any unsigned driver until Secure Boot is disabled (or you add your own signing key to BIOS/UEFI). By supporting Secure Boot, Ubuntu has made OS installation works out-of-the-box, otherwise you cannot even install the system (if so, I bet you'll complain how Ubuntu is gone for you, and how free and open source has terrible user experience - due to its absurd priority on the notation of freedom, does not even boot, and blablabla). TL;DR: Your rants are unwarranted. You can always disable Secure Boot, try disabling it first. If the UEFI on your PC doesn't allow you to disable Secure Boot, you can write a warranted angry post then, the conspiracy would be real (there used to be some evil embedded/tablet PCs that did this), otherwise it's not - you are free to disable Secure Boot, adding your signing key, optionally, even deleting Microsoft's signing key to fully control Secure Boot under your own discretion in the vast majority of PCs. > Even Windows you can just boot into a development mode and it might scream at you on the desktop, but it will allow you to modify your system as you wish. This is plain falsehood. Again, read the manual from Microsoft: If Secure Boot is enabled, you cannot boot into a development mode - the BCD setting is disabled. Windows does not allow you to modify your system as you wish. You cannot run, develop, or debug an unsigned kernel-mode driver unless you disable Secure Boot [0]. Disclaimer: I run Linux/BSD exclusively, I don't do any development on Windows, don't take my words for it, instead, check my citations to Microsoft's documentation. It's for Windows 8 32-bit that happened to be the first hit in my search, but I believe the policies are the same in Windows 10. Finally, locking down a system is not only used for DRM. Maybe you don't want it on a PC, but it's often desirable in production systems. For example, on my server, I completely disabled kernel modules, hotpatching, /dev/mem, etc., so that no code can even be loaded into the kernel (other people do the opposite, it's a tradeoff between uptime and security). There may still be some exploits that make it possible - PaX/grsecurity has better countermeasures and blocks additional attack vectors - but it's not available to the general public anymore. [0] https://docs.microsoft.com/en-us/windows/win32/w8cookbook/secured-boot-signing-requirements-for-kernel-mode-drivers https://docs.microsoft.com/en-us/windows/win32/w8cookbook/se...
david_draco 7y ago
Linux security has been criticised[1] for not having security enabled by default, and for allowing users to disable the security measures. This leads to users avoiding setting minimal-rights policies, and leaving the doors open. When security is optional, policy issues in distributions also aren't fixed quickly. To limit applications rights to a minimum, SELinux, firewalls, and (systemd) sandboxes are all tools that could be used, but aren't in most installs. However, I think we are still lacking user-friendly interfaces (opensnitch is ported from MacOS). One idea could be to let the desktop environment restrict one more capability a application on every run, inform the user before running it and ask the user after if the software worked correctly. That would gradually lead to a minimum set of software rights. [1] https://www.youtube.com/watch?v=OXS8ljif9b8 https://www.youtube.com/watch?v=OXS8ljif9b8
- indymike 7y ago
  This suggestion shows little understanding of the difference between Linux the kernel and Linux the OS distribution. It is the role of distributions to implement defaults for security. The idea, ask the user, is naive - most Linux software never interacts with a GUI or console user.
- deleted 7y ago
  [deleted]
- swiley 7y ago
  I think the reason security on Linux is so underused is because most of the software desktop Linux users run is very well behaved (compared to popular software on most consumer OSes.) I'd be willing to bet the majority of users aren't running anything closed source outside of a VM (and most that are probably only have one or two apps.) Closed desktop Linux apps are pretty unpleasant even when they run well. So there's little need for tools like SELinux and add to that how unpleasant they are to use and that's why no one uses them.
  - nickelpro 7y ago
    I'd be willing to bet the majority of users aren't running anything closed source outside of a VM That smacks of anecdote, as a counter anecdote I run plenty of closed source stuff on Linux and have no complaints.
bogomipz 7y ago
>Various interfaces make it straightforward for root to modify kernel code (such as loading modules or using /dev/mem), while others make it less straightforward (being able to load new ACPI tables that can cause the ACPI interpreter to overwrite the kernel, for instance). What exactly is the "ACPI interpreter" referenced here? I am familiar with ACPI but this is the first tine I have heard this term.
- detaro 7y ago
  ACPI tables contain byte code (AML), which needs to be interpreted by the kernel.
  - dirtydroog 7y ago
    It's amazing. A ring 0 bytecode interpreter.
- matheusmoreira 7y ago
  ACPI contains code! https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-system-description-tables https://docs.microsoft.com/en-us/windows-hardware/drivers/br... > ACPI defines an interpreted language (ACPI source language, or ASL) and an execution environment (ACPI virtual machine) for describing system devices and features, and their platform-specific controls, in an OS-agnostic way. > ASL is used to define named objects in the ACPI namespace, and the Microsoft ASL compiler is used to produce ACPI machine language (AML) byte code for transmission to the operating system in the DSDT. Linux drivers run this code via the acpi_evaluate_* functions. https://lwn.net/Articles/367630/ https://lwn.net/Articles/367630/ Microsoft defined another interface on top of ACPI called WMI. Unfortunately it seems to be widely used. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/implementing-wmi https://docs.microsoft.com/en-us/windows-hardware/drivers/ke... https://lwn.net/Articles/391230/ https://lwn.net/Articles/391230/ On Linux it's easy to extract and decompile the DSDT: $ cat /sys/firmware/acpi/tables/DSDT > dsdt.dat $ iasl -d dsdt.dat https://wiki.archlinux.org/index.php/DSDT https://wiki.archlinux.org/index.php/DSDT
- segfaultbuserr 7y ago
unixhero 7y ago
This is a serious improvement.
devit 7y ago
This is laughably useless. It's extremely unlikely they have patched all existing ways for root to change the kernel, and anyway since the kernel is written in C it almost surely has plenty of memory safety exploits. Also requiring an hypervisor is much simpler than doing this work and actually has a reasonable chance of achieving the objective of not allowing arbitrary ring 0 code. At any rate, all this work is mostly pointless because if you let people run arbitrary user space code, then they can do almost anything with the hardware anyway (like erasing all disks, etc.), and if you lock that down then you need to force them to use a particular user space and in that case there is no need to also lock down the kernel since without being able to run arbitrary user space code you can't interact with the kernel anyway.
- mjg59 7y ago
  How is requiring a hypervisor much simpler than this? I've seen no implementations that make strong integrity guarantees.
- fsflover 7y ago
  > Also requiring an hypervisor is much simpler I guess you are using Qubes OS, aren't you?
keyme 7y ago
Why is this considered a good thing? The only "security" this improves, is of devices where the manufacturer has decided to lock you out!
- detaro 7y ago
  Why doesn't it improve the security of devices where you decide to lock yourself out to protect against faulty applications? Don't you want your hosting provider to lock you and your neighbors out from the kernel running your processes, even if one of you manages to attack a privileged process?
- jcelerier 7y ago
  apparently some people miss UAC when they use linux
- saagarjha 7y ago
  It’s a good thing when you have control over whether it’s enabled, and how.
- paulcarroty 7y ago
  All depends from hardware vendor. A lot of modern Android smartphones has encrypted bootloader for example, so, nothing prevent them to lock-in your device right now.
  - JackRabbitSlim 7y ago
    Not exactly. That's why those same vendors work so hard at disabling root access for exactly the reasons outlined by the article; root can wreck it or maybe read out keys, or a million other little things because ALL of it is predicated on no one being able to just arbitrarily read/write to everything on the system like root/uid 1 can do.
- jsiepkes 7y ago
  > The only "security" this improves, is of devices where the manufacturer has decided to lock you out! Aside from me wanting to be able to verify the integrity of the boot chain and running OS (on platforms like servers, notebooks, etc) this has little to do with manufacturers locking you out. Secure boot is already in all machines and if the manufacturer wants they can already lock you out. They don't a bunch of code in the Linux kernel for that.
AshamedCaptain 7y ago
I find all the attempts at "curtailing down the powers of root" to be the modern equivalent of https://xkcd.com/1200/ https://xkcd.com/1200/ . At least with the "user vs admin" distinction, I could argue that it is useful becase my backups could be stored into a separate account with restricted access, so ransomware running in at the "user level" account, would not be able to touch them. While if my "admin" account gets compromised then all bets are off as the backups could be wiped out (even if they are offline, they could be wiped out the next time I connect the storage device). However I find a much harder time finding user justification for having a separate "root" vs "manufacturer root", unless you happen to be a manufacturer with questionable motives. If root is compromised, the attack surface becomes absolutely huge, and it doesn't seem to be very useful as a user the fact that I can rely that at least the kernel and bootloader will not be compromised if everything else is dubious. Sure, now I can trust that the builtin "restore to factory" functionality on the device works (and even that may not be true). But unless I use it frequently (and who does?), the malware with root access would still be able to destroy all of my files anyway, compromise my backups, etc.
- JackRabbitSlim 7y ago
  This is pretty much it. Let's frame the proposition differently to get people to consider it from a new perspective. I can verify the OS install media with trusted publishes using signing keys and PKI. I can't do a god damn thing about the cheap, back-doored PCI controller from China. What protection does secure boot really offer the end user at that point? The PCI controller is in place to just pass the right signatures to secure boot or just wait until after the secure boot checks so it's not helping with bad hardware. I already verified the OS media at install, so its not super useful there either. Did my boot code change? How would I know? Did the bad PCI controller fake it? Do I have any additional trust in my system? I can't go probing the system to try to find out. A black box with zero control told you you were safe and there is no way to look at or modify the system now so you can trust it. Your hardware was never on a TAO workbench. Who doesn't feel safer?
  - mjg59 7y ago
    > I can't do a god damn thing about the cheap, back-doored PCI controller from China. Of course you can - that's what IOMMUs are for.
rrss 7y ago
Since this is controlled via a kernel parameter, can root just unset the kernel parameter and reboot? Or are there systems where kernel parameters are also 'locked down' by some other mechanism? (these are genuine questions - I don't know much about linux security and am seeking to understand).
- diath 7y ago
  I believe it's a set of kernel build flags and not a kernel parameter, in which case, not really, I initially said you could just replace the kernel with something that's been built without the flags and reboot but apparently the second paragraph says it prevents that, though I'm not sure how would updating the kernel work in that case then.
  - rrss 7y ago
    There are build config options, but there's also a kernel parameter > lockdown= [SECURITY] { integrity | confidentiality } https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt https://www.kernel.org/doc/Documentation/admin-guide/kernel-...
    - diath 7y ago
      I missed that part, so I'm honestly as puzzled as you are (I suppose the answer would be yes then).
    - Spivak 7y ago
      You need GRUB's help do do this. There is a 'verify' module you can use that makes GRUB load files that are signed with a given GPG key. You build a GRUB efi binary that contains your key and only loads signed config files, initrds, and kernels and then sign that binary so that it can be loaded by UEFI.
- mjg59 7y ago
  Most distributions carry a patch to automatically enable this if you have a verified boot process. Otherwise, it's up to the admin to ensure that their verified boot process applies the appropriate policy (eg, by ensuring that your bootloader appends the argument regardless of configuration)

142 points by JNRowe 7y ago

I think Fedora Silverblue takes a very different approach here - https://docs.fedoraproject.org/en-US/fedora-silverblue/ https://docs.fedoraproject.org/en-US/fedora-silverblue/ It basically doesn't try to fix the building blocks with all their legacy...instead it simply makes the entire operating system immutable. I wonder what are the pros and cons of each approach. Or are they complementary.

jchw 7y ago
Complementary. Silverblue’s immutability may be aimed purely at stability and therefore may not have strong guarantees, but if it did then the next attack vector would be from root to kernel (in memory), and that’s where lockdown comes in; it’s designed to prevent attacking a running kernel as root.

jasonhansel 7y ago

Another option might be to allow a "rootless" mode in which direct access to the root account itself is impossible (but where there are still ways for non-root users to gain a subset of root capabilities).

lwb 7y ago

Possibly a dumb question -- how can one perform kernel/firmware updates if root is "locked out"?

Ao7bei3s 7y ago
The integrity mode applies to the running kernel in RAM. You generally don't actually upgrade that, instead you replace the kernel image on disk (vmlinuz), which is still possible. On next boot, the new image will be loaded. But if you have trusted boot enabled, the new image will only be booted if it is appropriately signed. Live patching still works if the updates are signed. The kernel can still do whatever - with integrity enabled it just refuses to do certain things, such as loading kernel modules or updates that aren't signed.
- lwb 7y ago
  Great explanation, thanks!

staticassertion 7y ago

Surprised no one has yet commented on eBPF, and the impact this has. ebpf already gives users the right to run code as the kernel, and this is a security win in many cases - you can audit your system better. On a server, I think I'd rather assume the attacker has root (or even kernel!) but have good auditing, and do specific service sandboxing, than assume that I can separate root from kernel. My understanding is that confidentiality breaks ebpf. I'm unsure about integrity - if integrity works with it, great. Then I'd wonder where you'd want confidentiality - maybe a box that's handling CC info/ payment processing? I have mixed feelings overall.

mjg59 7y ago
Integrity doesn't restrict ebpf. Confidentiality is for cases where you're doing stuff like using EVM to prevent offline attacks, which involves the kernel holding a key and using it to sign all files. This can be circumvented if you're able to just scrape the secret out of the kernel.
- staticassertion 7y ago
  Cool, that sounds reasonable then. Good stuff.

freedomben 7y ago

This lockdown made it a huge PITA to run Wireguard in Fedora[1]. It broke existing installs when the kernel upgraded and then became very difficult to insmod or modprobe the wireguard kernel modules unless you blacklisted all new kernels (not safe). I hope this matures in a way that doesn't destroy some of the reasons I love Linux (that I can hack on my system and do cool stuff). [1] https://unix.stackexchange.com/q/543576/34855 https://unix.stackexchange.com/q/543576/34855

htfy96 7y ago
Wireguard is merged into the mainline and would possibly appear in Fedora 32 on 5.6. Fedora 32 will be released several weeks later. The underlying problem is that many distro just use a throwaway pubkey which makes users impossible to sign their modules. Maybe a better security model is needed.
- freedomben 7y ago
  yeah for this reason I've been super excited for kernel 5.6 (I don't usually get excited for new kernel releases cause it means work for me, but this one is different :party: )
jamielinux 7y ago
You can sign modules using these instructions: https://docs.fedoraproject.org/en-US/fedora/f31/system-administrators-guide/kernel-module-driver-configuration/Working_with_Kernel_Modules/#sect-signing-kernel-modules-for-secure-boot https://docs.fedoraproject.org/en-US/fedora/f31/system-admin... Though it's definitely a faff, and it's required every time there's kernel upgrade.

stefan_ 7y ago

Do people realize what they are doing here? I'm happy not touching my Windows kernel, stuff generally just works. Stuff never just works on Linux. And now the last time I tried to load a kernel module I had built for my Ubuntu system, it refused because, duh, it wasn't signed by some UEFI key I had never even seen. So now of course, the Ubuntu is fucking gone. Because it makes it impossible to do things that on Linux are still a monthly requirement. Not to mention the impact this stuff has on kernel and driver development. Even Windows you can just boot into a development mode and it might scream at you on the desktop, but it will allow you to modify your system as you wish. I wasted a few hours when that Ubuntu thing happened to figure out where that switch was and didn't find it. Right now, this should be strictly the domain of Google and Amazon that can actually have a trusted chain from bootloader to userland. Not enabled on any vanilla Ubuntu because hey, we detected UEFI!

segfaultbuserr 7y ago
> And now the last time I tried to load a kernel module I had built for my Ubuntu system, it refused because, duh, it wasn't signed by some UEFI key I had never even seen. So now of course, the Ubuntu is fucking gone. There is no conspiracy here. The option you are looking for is in your BIOS/UEFI, not in the OS. You should have known better and read the fucking manual. Your machine comes with Secure Boot enabled by default, by the policy of Secure Boot, there are two possible outcomes. 1. If the OS doesn't support Secure Boot, you cannot boot the OS until Secure Boot is disabled (or you add your own signing key to BIOS/UEFI). 2. If the OS supports Secure Boot and signed by a big firm, you can boot it by default, but by the policy, it cannot execute any unsigned driver until Secure Boot is disabled (or you add your own signing key to BIOS/UEFI). By supporting Secure Boot, Ubuntu has made OS installation works out-of-the-box, otherwise you cannot even install the system (if so, I bet you'll complain how Ubuntu is gone for you, and how free and open source has terrible user experience - due to its absurd priority on the notation of freedom, does not even boot, and blablabla). TL;DR: Your rants are unwarranted. You can always disable Secure Boot, try disabling it first. If the UEFI on your PC doesn't allow you to disable Secure Boot, you can write a warranted angry post then, the conspiracy would be real (there used to be some evil embedded/tablet PCs that did this), otherwise it's not - you are free to disable Secure Boot, adding your signing key, optionally, even deleting Microsoft's signing key to fully control Secure Boot under your own discretion in the vast majority of PCs. > Even Windows you can just boot into a development mode and it might scream at you on the desktop, but it will allow you to modify your system as you wish. This is plain falsehood. Again, read the manual from Microsoft: If Secure Boot is enabled, you cannot boot into a development mode - the BCD setting is disabled. Windows does not allow you to modify your system as you wish. You cannot run, develop, or debug an unsigned kernel-mode driver unless you disable Secure Boot [0]. Disclaimer: I run Linux/BSD exclusively, I don't do any development on Windows, don't take my words for it, instead, check my citations to Microsoft's documentation. It's for Windows 8 32-bit that happened to be the first hit in my search, but I believe the policies are the same in Windows 10. Finally, locking down a system is not only used for DRM. Maybe you don't want it on a PC, but it's often desirable in production systems. For example, on my server, I completely disabled kernel modules, hotpatching, /dev/mem, etc., so that no code can even be loaded into the kernel (other people do the opposite, it's a tradeoff between uptime and security). There may still be some exploits that make it possible - PaX/grsecurity has better countermeasures and blocks additional attack vectors - but it's not available to the general public anymore. [0] https://docs.microsoft.com/en-us/windows/win32/w8cookbook/secured-boot-signing-requirements-for-kernel-mode-drivers https://docs.microsoft.com/en-us/windows/win32/w8cookbook/se...

david_draco 7y ago

Linux security has been criticised[1] for not having security enabled by default, and for allowing users to disable the security measures. This leads to users avoiding setting minimal-rights policies, and leaving the doors open. When security is optional, policy issues in distributions also aren't fixed quickly. To limit applications rights to a minimum, SELinux, firewalls, and (systemd) sandboxes are all tools that could be used, but aren't in most installs. However, I think we are still lacking user-friendly interfaces (opensnitch is ported from MacOS). One idea could be to let the desktop environment restrict one more capability a application on every run, inform the user before running it and ask the user after if the software worked correctly. That would gradually lead to a minimum set of software rights. [1] https://www.youtube.com/watch?v=OXS8ljif9b8 https://www.youtube.com/watch?v=OXS8ljif9b8

indymike 7y ago
This suggestion shows little understanding of the difference between Linux the kernel and Linux the OS distribution. It is the role of distributions to implement defaults for security. The idea, ask the user, is naive - most Linux software never interacts with a GUI or console user.
deleted 7y ago
[deleted]
swiley 7y ago
I think the reason security on Linux is so underused is because most of the software desktop Linux users run is very well behaved (compared to popular software on most consumer OSes.) I'd be willing to bet the majority of users aren't running anything closed source outside of a VM (and most that are probably only have one or two apps.) Closed desktop Linux apps are pretty unpleasant even when they run well. So there's little need for tools like SELinux and add to that how unpleasant they are to use and that's why no one uses them.
- nickelpro 7y ago
  I'd be willing to bet the majority of users aren't running anything closed source outside of a VM That smacks of anecdote, as a counter anecdote I run plenty of closed source stuff on Linux and have no complaints.

bogomipz 7y ago

>Various interfaces make it straightforward for root to modify kernel code (such as loading modules or using /dev/mem), while others make it less straightforward (being able to load new ACPI tables that can cause the ACPI interpreter to overwrite the kernel, for instance). What exactly is the "ACPI interpreter" referenced here? I am familiar with ACPI but this is the first tine I have heard this term.

detaro 7y ago
ACPI tables contain byte code (AML), which needs to be interpreted by the kernel.
- dirtydroog 7y ago
  It's amazing. A ring 0 bytecode interpreter.
matheusmoreira 7y ago
ACPI contains code! https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-system-description-tables https://docs.microsoft.com/en-us/windows-hardware/drivers/br... > ACPI defines an interpreted language (ACPI source language, or ASL) and an execution environment (ACPI virtual machine) for describing system devices and features, and their platform-specific controls, in an OS-agnostic way. > ASL is used to define named objects in the ACPI namespace, and the Microsoft ASL compiler is used to produce ACPI machine language (AML) byte code for transmission to the operating system in the DSDT. Linux drivers run this code via the acpi_evaluate_* functions. https://lwn.net/Articles/367630/ https://lwn.net/Articles/367630/ Microsoft defined another interface on top of ACPI called WMI. Unfortunately it seems to be widely used. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/implementing-wmi https://docs.microsoft.com/en-us/windows-hardware/drivers/ke... https://lwn.net/Articles/391230/ https://lwn.net/Articles/391230/ On Linux it's easy to extract and decompile the DSDT: $ cat /sys/firmware/acpi/tables/DSDT > dsdt.dat $ iasl -d dsdt.dat https://wiki.archlinux.org/index.php/DSDT https://wiki.archlinux.org/index.php/DSDT
segfaultbuserr 7y ago

unixhero 7y ago

This is a serious improvement.

devit 7y ago

This is laughably useless. It's extremely unlikely they have patched all existing ways for root to change the kernel, and anyway since the kernel is written in C it almost surely has plenty of memory safety exploits. Also requiring an hypervisor is much simpler than doing this work and actually has a reasonable chance of achieving the objective of not allowing arbitrary ring 0 code. At any rate, all this work is mostly pointless because if you let people run arbitrary user space code, then they can do almost anything with the hardware anyway (like erasing all disks, etc.), and if you lock that down then you need to force them to use a particular user space and in that case there is no need to also lock down the kernel since without being able to run arbitrary user space code you can't interact with the kernel anyway.

mjg59 7y ago
How is requiring a hypervisor much simpler than this? I've seen no implementations that make strong integrity guarantees.
fsflover 7y ago
> Also requiring an hypervisor is much simpler I guess you are using Qubes OS, aren't you?

keyme 7y ago

Why is this considered a good thing? The only "security" this improves, is of devices where the manufacturer has decided to lock you out!

detaro 7y ago
Why doesn't it improve the security of devices where you decide to lock yourself out to protect against faulty applications? Don't you want your hosting provider to lock you and your neighbors out from the kernel running your processes, even if one of you manages to attack a privileged process?
jcelerier 7y ago
apparently some people miss UAC when they use linux
saagarjha 7y ago
It’s a good thing when you have control over whether it’s enabled, and how.
paulcarroty 7y ago
All depends from hardware vendor. A lot of modern Android smartphones has encrypted bootloader for example, so, nothing prevent them to lock-in your device right now.
- JackRabbitSlim 7y ago
  Not exactly. That's why those same vendors work so hard at disabling root access for exactly the reasons outlined by the article; root can wreck it or maybe read out keys, or a million other little things because ALL of it is predicated on no one being able to just arbitrarily read/write to everything on the system like root/uid 1 can do.
jsiepkes 7y ago
> The only "security" this improves, is of devices where the manufacturer has decided to lock you out! Aside from me wanting to be able to verify the integrity of the boot chain and running OS (on platforms like servers, notebooks, etc) this has little to do with manufacturers locking you out. Secure boot is already in all machines and if the manufacturer wants they can already lock you out. They don't a bunch of code in the Linux kernel for that.

AshamedCaptain 7y ago

I find all the attempts at "curtailing down the powers of root" to be the modern equivalent of https://xkcd.com/1200/ https://xkcd.com/1200/ . At least with the "user vs admin" distinction, I could argue that it is useful becase my backups could be stored into a separate account with restricted access, so ransomware running in at the "user level" account, would not be able to touch them. While if my "admin" account gets compromised then all bets are off as the backups could be wiped out (even if they are offline, they could be wiped out the next time I connect the storage device). However I find a much harder time finding user justification for having a separate "root" vs "manufacturer root", unless you happen to be a manufacturer with questionable motives. If root is compromised, the attack surface becomes absolutely huge, and it doesn't seem to be very useful as a user the fact that I can rely that at least the kernel and bootloader will not be compromised if everything else is dubious. Sure, now I can trust that the builtin "restore to factory" functionality on the device works (and even that may not be true). But unless I use it frequently (and who does?), the malware with root access would still be able to destroy all of my files anyway, compromise my backups, etc.

JackRabbitSlim 7y ago
This is pretty much it. Let's frame the proposition differently to get people to consider it from a new perspective. I can verify the OS install media with trusted publishes using signing keys and PKI. I can't do a god damn thing about the cheap, back-doored PCI controller from China. What protection does secure boot really offer the end user at that point? The PCI controller is in place to just pass the right signatures to secure boot or just wait until after the secure boot checks so it's not helping with bad hardware. I already verified the OS media at install, so its not super useful there either. Did my boot code change? How would I know? Did the bad PCI controller fake it? Do I have any additional trust in my system? I can't go probing the system to try to find out. A black box with zero control told you you were safe and there is no way to look at or modify the system now so you can trust it. Your hardware was never on a TAO workbench. Who doesn't feel safer?
- mjg59 7y ago
  > I can't do a god damn thing about the cheap, back-doored PCI controller from China. Of course you can - that's what IOMMUs are for.

rrss 7y ago

Since this is controlled via a kernel parameter, can root just unset the kernel parameter and reboot? Or are there systems where kernel parameters are also 'locked down' by some other mechanism? (these are genuine questions - I don't know much about linux security and am seeking to understand).

diath 7y ago
I believe it's a set of kernel build flags and not a kernel parameter, in which case, not really, I initially said you could just replace the kernel with something that's been built without the flags and reboot but apparently the second paragraph says it prevents that, though I'm not sure how would updating the kernel work in that case then.
- rrss 7y ago
  There are build config options, but there's also a kernel parameter > lockdown= [SECURITY] { integrity | confidentiality } https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt https://www.kernel.org/doc/Documentation/admin-guide/kernel-...
  - diath 7y ago
    I missed that part, so I'm honestly as puzzled as you are (I suppose the answer would be yes then).
  - Spivak 7y ago
    You need GRUB's help do do this. There is a 'verify' module you can use that makes GRUB load files that are signed with a given GPG key. You build a GRUB efi binary that contains your key and only loads signed config files, initrds, and kernels and then sign that binary so that it can be loaded by UEFI.
mjg59 7y ago
Most distributions carry a patch to automatically enable this if you have a verified boot process. Otherwise, it's up to the admin to ensure that their verified boot process applies the appropriate policy (eg, by ensuring that your bootloader appends the argument regardless of configuration)