Hacker News Reader

Comment by bayindirh | Hacker News Reader

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.

View on HN

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.

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

> 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.

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.

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.

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.

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.

Honestly I can't remember the last time I had an issue with SELinux on any of my desktop systems. I've had to work past some issues with systems I manage for work, but those weren't too bad to deal with.

SELinux is enabled by default on many production-grade distros, most notable Fedora. It's the distro maintainer's duty to ship policies. Yes, you need to write policy files for bespoke software, but SELinux has gotten better at helping to generate these.

I've been running Fedora for about 2 years, and have never been tempted yet to turn off selinux. (And I just used the 'sestatus' command to verify that it is enabled. "Current mode: enforcing", it elaborates.)

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

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/

I don't know what this is, but it appears to be shared-kernel.

Apptainer works the same way as Docker. It just makes using it for distributing applications more convenient.

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?

> 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?

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.

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

1. https://sel4.systems/About/Performance/

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

Reply on news.ycombinator.com