5 ms·

Yet these escalation CVEs are getting rarer and rarer, while production systems are generally hardened with SELinux and AppArmor out of the box, making practica

Yet these escalation CVEs are getting rarer and rarer, while production systems are generally hardened with SELinux and AppArmor out of the box, making practically exploiting them much harder. The gist, is it requires a local user to be able to run processes, and not to be bound by SELinux or AppArmor to succeed. It should be patched, but it's not Heartbleed. P.S.: I didn't want to open the box of performance issues of microkernels, yet somebody did, and yes, performance matters.

codedokode 3y ago
> P.S.: I didn't want to open the box of performance issues of microkernels Why are there performance issues? Are there any reasons for them except for context switch costs (which are only due to legacy CPU architectures that were optimized for outdated insecure OSes)? Is microkernel architecture somehow incompatible with good performance?
- samus 3y ago
  Microkernel architecture pretty much requires that processes communicate via explicitly defined interfaces, usually message passing. And it becomes much more difficult for subsystems to coordinate low-level activities, which is crucial for performance optimizations. And yes, context switches matter a lot too.
  - snvzz 3y ago
    Lots of myths around microkernel "slowness"[0]. >And yes, context switches matter a lot too. seL4 is significantly (100x-1000x) faster than Linux at context switching[1]. At the same time, it does not require that many more context switches. 0. https://archive.is/30hhi https://archive.is/30hhi 1. https://sel4.systems/About/Performance/ https://sel4.systems/About/Performance/
    - kramerger 3y ago
      This is a very unfair comparison 1. A sel4 context switch does significantly less than a Linux ditto. It saves fewer hardware registers etc 2. You will need many more context switches to achieve the same thing in a microkernel due to its distributed architecture. 3. A lot of "complexity" in the kernel is simply performance optimization that does not exist in sel4. Back in the days Minix and Hurd promised to achieve optimization by replacing generic servers with custom ones but I haven't seen this actually working in 20 years
codedokode 3y ago
> while production systems are generally hardened with SELinux and AppArmor out of the box, making practically exploiting them much harder. Is it really so? I get an impression that SELinux is a so complicated that nobody wants to bother with setting it up and everyone disables it as soon as possible.
- mikaraento 3y ago
  You are correct about SELinux in general terms. However, there is a large scale exception to this: Android. Android uses SELinux extensively, and it is also used as part of further sandboxes in Chrome and Android System Intelligence.
- bayindirh 3y ago
  We don't disable SELinux unless the software explicitly requires it. Also, all of the machines running without SELinux are not accessible from outside. SELinux is complicated, but it's not impossible to work with. Configuring new rules is another story, though.
- gizmo686 3y ago
  RHEL systems run SELinux in enforcing mode by default. Most applications run in a domain called "unconfined_t", which is about as secure as it sounds. [0] Ubuntu runs AppArmor in its version of enforcing mode. I've only ever run into issues with it once though, so I presume it is a similarly lax policy. [0] The policy is called "targeted", to reflect the fact that you are supposed to write targeted policy modules for specific applications you are concerned about.
  - bayindirh 3y ago
    Debian’s AppArmor policy is pretty strict, yet well refined. As long as you use standard folders and paths, it’s pretty invisible. Last time while I was migrating a DNS server, our zone folders were not in a standard path, and Bind was unable to find them. 10 minutes later I remembered about AppArmor, and moved the files. The only problematic hardening was Thunderbird, which broke attachments. They disabled the Thunderbird’s profile after failing to fix it. Currently I’m on mobile, so I can’t give you a list of active profiles, yet the list is not short and the policy is not lax. I worked with both of them back in the day and developed profiles for them. Update: Stats are as follows: 78 packages ship AppArmor profiles in Debian 12. Notable are: - mariadb-server - redshift (f.lux alternative) - bind - ioquake3 (yes, the game) - squid - tcpdump among others. Also there are "apparmor-profiles" and "apparmor-profiles-extra" packages which provides profiles for vsftpd, dovecot, dhcpd amongst others (141 in profiles and 10 in extras). So, AppArmor ecosystem is neither lax, nor unmaintained.
gizmo686 3y ago
I don't see how SELinux or AppArmor would help here. From the details provided, it looks like all that is needed is mmap. At most it "requires minimal capabilities to trigger" based on the article. Granted, it is possible to deny mmap permissions, but I don’t think most policy writers would consider mmap a particular dangerous permission to grant. I just checked my CentOS 8 system running stock policy, and every process type has permission to map every file type. Granted, this is gated behind a boolean, so an administrator could disable it if they wanted to, but the default is true. Not that it is relevant to this issue where it doesn't matter what you mmap; but since I know someone will ask, having mmap permission does not bypass the check on, for example, read permission.
- blibble 3y ago
  you "disable" mmap and you will break: - dynamic loading - malloc - any just in time compilers it is a core feature of a modern operating system
tptacek 3y ago
It's worse than Heartbleed for anyone doing shared-kernel multitenant (running Docker containers from mutually untrusting sources). There are a bunch of those!
- bayindirh 3y ago
  If you're running multi-tenant Docker, you're doing something wrong to begin with. There are better solutions like Apptainer [0]. [0]: https://apptainer.org/ https://apptainer.org/
  - tptacek 3y ago
    I don't know what this is, but it appears to be shared-kernel.
  - IshKebab 3y ago
    Apptainer works the same way as Docker. It just makes using it for distributing applications more convenient.
- hollerith 3y ago
  Does browsing the web with Javascript turned on on the same kernel where I ssh from (and consequently keep my ssh credentials) count as multitenanted here?

codedokode 3y ago

> P.S.: I didn't want to open the box of performance issues of microkernels Why are there performance issues? Are there any reasons for them except for context switch costs (which are only due to legacy CPU architectures that were optimized for outdated insecure OSes)? Is microkernel architecture somehow incompatible with good performance?

samus 3y ago
Microkernel architecture pretty much requires that processes communicate via explicitly defined interfaces, usually message passing. And it becomes much more difficult for subsystems to coordinate low-level activities, which is crucial for performance optimizations. And yes, context switches matter a lot too.
- snvzz 3y ago
  Lots of myths around microkernel "slowness"[0]. >And yes, context switches matter a lot too. seL4 is significantly (100x-1000x) faster than Linux at context switching[1]. At the same time, it does not require that many more context switches. 0. https://archive.is/30hhi https://archive.is/30hhi 1. https://sel4.systems/About/Performance/ https://sel4.systems/About/Performance/
  - kramerger 3y ago
    This is a very unfair comparison 1. A sel4 context switch does significantly less than a Linux ditto. It saves fewer hardware registers etc 2. You will need many more context switches to achieve the same thing in a microkernel due to its distributed architecture. 3. A lot of "complexity" in the kernel is simply performance optimization that does not exist in sel4. Back in the days Minix and Hurd promised to achieve optimization by replacing generic servers with custom ones but I haven't seen this actually working in 20 years

codedokode 3y ago

> while production systems are generally hardened with SELinux and AppArmor out of the box, making practically exploiting them much harder. Is it really so? I get an impression that SELinux is a so complicated that nobody wants to bother with setting it up and everyone disables it as soon as possible.

mikaraento 3y ago
You are correct about SELinux in general terms. However, there is a large scale exception to this: Android. Android uses SELinux extensively, and it is also used as part of further sandboxes in Chrome and Android System Intelligence.
bayindirh 3y ago
We don't disable SELinux unless the software explicitly requires it. Also, all of the machines running without SELinux are not accessible from outside. SELinux is complicated, but it's not impossible to work with. Configuring new rules is another story, though.
gizmo686 3y ago
RHEL systems run SELinux in enforcing mode by default. Most applications run in a domain called "unconfined_t", which is about as secure as it sounds. [0] Ubuntu runs AppArmor in its version of enforcing mode. I've only ever run into issues with it once though, so I presume it is a similarly lax policy. [0] The policy is called "targeted", to reflect the fact that you are supposed to write targeted policy modules for specific applications you are concerned about.
- bayindirh 3y ago
  Debian’s AppArmor policy is pretty strict, yet well refined. As long as you use standard folders and paths, it’s pretty invisible. Last time while I was migrating a DNS server, our zone folders were not in a standard path, and Bind was unable to find them. 10 minutes later I remembered about AppArmor, and moved the files. The only problematic hardening was Thunderbird, which broke attachments. They disabled the Thunderbird’s profile after failing to fix it. Currently I’m on mobile, so I can’t give you a list of active profiles, yet the list is not short and the policy is not lax. I worked with both of them back in the day and developed profiles for them. Update: Stats are as follows: 78 packages ship AppArmor profiles in Debian 12. Notable are: - mariadb-server - redshift (f.lux alternative) - bind - ioquake3 (yes, the game) - squid - tcpdump among others. Also there are "apparmor-profiles" and "apparmor-profiles-extra" packages which provides profiles for vsftpd, dovecot, dhcpd amongst others (141 in profiles and 10 in extras). So, AppArmor ecosystem is neither lax, nor unmaintained.

gizmo686 3y ago

I don't see how SELinux or AppArmor would help here. From the details provided, it looks like all that is needed is mmap. At most it "requires minimal capabilities to trigger" based on the article. Granted, it is possible to deny mmap permissions, but I don’t think most policy writers would consider mmap a particular dangerous permission to grant. I just checked my CentOS 8 system running stock policy, and every process type has permission to map every file type. Granted, this is gated behind a boolean, so an administrator could disable it if they wanted to, but the default is true. Not that it is relevant to this issue where it doesn't matter what you mmap; but since I know someone will ask, having mmap permission does not bypass the check on, for example, read permission.

blibble 3y ago
you "disable" mmap and you will break: - dynamic loading - malloc - any just in time compilers it is a core feature of a modern operating system

tptacek 3y ago

It's worse than Heartbleed for anyone doing shared-kernel multitenant (running Docker containers from mutually untrusting sources). There are a bunch of those!

bayindirh 3y ago
If you're running multi-tenant Docker, you're doing something wrong to begin with. There are better solutions like Apptainer [0]. [0]: https://apptainer.org/ https://apptainer.org/
- tptacek 3y ago
  I don't know what this is, but it appears to be shared-kernel.
- IshKebab 3y ago
  Apptainer works the same way as Docker. It just makes using it for distributing applications more convenient.
hollerith 3y ago
Does browsing the web with Javascript turned on on the same kernel where I ssh from (and consequently keep my ssh credentials) count as multitenanted here?