5 ms·

OSS-SEC: Three bypasses of Ubuntu's unprivileged user namespace restrictions

73 points by birdculture 2y ago

mjevans 2y ago
So, entirely, AppArmor profiles for shipped executables allow escape from privileged environments... Without that additional AppArmor 'blessing', wouldn't the standard Linux privileges / container groups prevent this?
- bri3d 2y ago
  No; note the last sentence in the article: "a bypass is not even needed on most Linux distributions, because they allow unprivileged users to obtain full capabilities inside namespaces by default (and therefore to exploit CAP_SYS_ADMIN kernel vulnerabilities for example), without any restriction at all." From the kernel standpoint, without a rules engine (AppArmor, seccomp, SELinux), unprivileged user namespaces are an all-or-nothing thing (unprivileged_userns_clone), so distributions have to rely on complex and leaky rules engines to try to allow namespace segmentation without letting users touch the big, broken kernel too much.
o11c 2y ago
Important caveat: this is not itself a vulnerability; you still need a kernel `CAP_SYS_ADMIN` vulnerability if you want to actually do something evil. (I also expect that if you're already in a restricted AA profile it's not easy to switch to a less-restrictive one, but I think a lot of security tools are bad at thinking about multi-process interpreters)
deleted 2y ago
[deleted]
j45 2y ago
With the Linux kernel references is this only a Ubuntu issue, or could Debian also be affected?
- theamk 2y ago
  I see no mention of "userns" in debian's apparmor.d, which means Debian is unaffected because it does not implement such protection at all. An analogy: Ubuntu has installed a lock on a window which turned out to be easily broken. Debian was unaffected because it just kept that window unlocked - no lock, no vulnerability.
  - curt15 2y ago
    Fedora and RHEL 8+ also don't restrict unprivileged user namespaces. They are required for flatpak and rootless podman, both widely used and promoted technologies in the Red Hat ecosystem.
    - fpoling 2y ago
      Flatpack does not require user namespaces. bubblewrap, the tool Flatpack uses to secure things, can be installed set-uid and can then setup the sandbox without the user namespaces. Chromium-based browsers also include own setuid tool to setup the sandbox if the user-namespaces are not available. Even podman could have used something like that. But I guess RedHat assumes that the user namespaces are solid these days are do not bother…
    - worthless-trash 2y ago
      > Fedora and RHEL 8+ also don't restrict unprivileged user namespaces. Are you sure ? Its disabled by default boot on my systems.
  - udev4096 2y ago
    Debian is still way worse. Do not use it. Instead, stick to fedora or arch
    - eqvinox 2y ago
      If you post something like this, you need to have arguments and links in it. No matter how well founded your opinion might be, noone knows what solid basis you have (or don't) and as such your comment is just badmouthing.
quotemstr 2y ago
Unprivileged user namespaces are not a security vulnerability. Ubuntu's short-sighted and reactionary decision to ban them makes systems less, not more, secure overall, since with this capability gone, it makes it that much harder for a well-behaved unprivileged program to set up a userspace sandbox. If the kernel has vulnerabilities, fix them. Don't just randomly break useful features.
- gizmo686 2y ago
  Broken security boundaries are actively harmful. If you offer something that looks like a security boundary, then people will design their systems on the assumption that it does what it looks like it does. Doubly so if it is actually documented as a security feature. They will then _not_ look into alternative mechanisms to achieve their security goals, even when those alternatives exist and are less susceptible to holes. Yes, the kernel should be fixed. But until the kernel is fixed, distributions should not be enabling broken features by default.
  - quotemstr 2y ago
    This attitude is why operating systems have ossified. Every new feature is suspect. io_uring? TURN IT OFF. User namespaces? TURN IT OFF. eBPF? TURN IT OFF. This superstitiousness is making it hard for application authors to use new features and advance the state of the art. The kernel should not have random knobs for disabling new technology. > But until the kernel is fixed The kernel is in fact fixed. The occasional bug doesn't obviate the maturity of the system. If it did, you wouldn't use Linux at all
    - rini17 2y ago
      Attack surface is a thing, still.
    - yjftsjthsd-h 2y ago
      > This attitude is why operating systems have ossified. Every new feature is suspect. io_uring? TURN IT OFF. User namespaces? TURN IT OFF. eBPF? TURN IT OFF. This superstitiousness It's not "superstitiousness" when the new features did in fact have vulnerabilities.
eqvinox 2y ago
It's "only" the failure of one layer of security. But also: It's the failure of one layer of security. As much as I agree it's not a big breach, it's not great. Especially if people are aware these profile security features exist, rely on them (maybe more than intended) and then you add a break like this.

73 points by birdculture 2y ago

So, entirely, AppArmor profiles for shipped executables allow escape from privileged environments... Without that additional AppArmor 'blessing', wouldn't the standard Linux privileges / container groups prevent this?

bri3d 2y ago
No; note the last sentence in the article: "a bypass is not even needed on most Linux distributions, because they allow unprivileged users to obtain full capabilities inside namespaces by default (and therefore to exploit CAP_SYS_ADMIN kernel vulnerabilities for example), without any restriction at all." From the kernel standpoint, without a rules engine (AppArmor, seccomp, SELinux), unprivileged user namespaces are an all-or-nothing thing (unprivileged_userns_clone), so distributions have to rely on complex and leaky rules engines to try to allow namespace segmentation without letting users touch the big, broken kernel too much.

o11c 2y ago

Important caveat: this is not itself a vulnerability; you still need a kernel `CAP_SYS_ADMIN` vulnerability if you want to actually do something evil. (I also expect that if you're already in a restricted AA profile it's not easy to switch to a less-restrictive one, but I think a lot of security tools are bad at thinking about multi-process interpreters)

deleted 2y ago

[deleted]

j45 2y ago

With the Linux kernel references is this only a Ubuntu issue, or could Debian also be affected?

theamk 2y ago
I see no mention of "userns" in debian's apparmor.d, which means Debian is unaffected because it does not implement such protection at all. An analogy: Ubuntu has installed a lock on a window which turned out to be easily broken. Debian was unaffected because it just kept that window unlocked - no lock, no vulnerability.
- curt15 2y ago
  Fedora and RHEL 8+ also don't restrict unprivileged user namespaces. They are required for flatpak and rootless podman, both widely used and promoted technologies in the Red Hat ecosystem.
  - fpoling 2y ago
    Flatpack does not require user namespaces. bubblewrap, the tool Flatpack uses to secure things, can be installed set-uid and can then setup the sandbox without the user namespaces. Chromium-based browsers also include own setuid tool to setup the sandbox if the user-namespaces are not available. Even podman could have used something like that. But I guess RedHat assumes that the user namespaces are solid these days are do not bother…
  - worthless-trash 2y ago
    > Fedora and RHEL 8+ also don't restrict unprivileged user namespaces. Are you sure ? Its disabled by default boot on my systems.
- udev4096 2y ago
  Debian is still way worse. Do not use it. Instead, stick to fedora or arch
  - eqvinox 2y ago
    If you post something like this, you need to have arguments and links in it. No matter how well founded your opinion might be, noone knows what solid basis you have (or don't) and as such your comment is just badmouthing.

quotemstr 2y ago

Unprivileged user namespaces are not a security vulnerability. Ubuntu's short-sighted and reactionary decision to ban them makes systems less, not more, secure overall, since with this capability gone, it makes it that much harder for a well-behaved unprivileged program to set up a userspace sandbox. If the kernel has vulnerabilities, fix them. Don't just randomly break useful features.

gizmo686 2y ago
Broken security boundaries are actively harmful. If you offer something that looks like a security boundary, then people will design their systems on the assumption that it does what it looks like it does. Doubly so if it is actually documented as a security feature. They will then _not_ look into alternative mechanisms to achieve their security goals, even when those alternatives exist and are less susceptible to holes. Yes, the kernel should be fixed. But until the kernel is fixed, distributions should not be enabling broken features by default.
- quotemstr 2y ago
  This attitude is why operating systems have ossified. Every new feature is suspect. io_uring? TURN IT OFF. User namespaces? TURN IT OFF. eBPF? TURN IT OFF. This superstitiousness is making it hard for application authors to use new features and advance the state of the art. The kernel should not have random knobs for disabling new technology. > But until the kernel is fixed The kernel is in fact fixed. The occasional bug doesn't obviate the maturity of the system. If it did, you wouldn't use Linux at all
  - rini17 2y ago
    Attack surface is a thing, still.
  - yjftsjthsd-h 2y ago
    > This attitude is why operating systems have ossified. Every new feature is suspect. io_uring? TURN IT OFF. User namespaces? TURN IT OFF. eBPF? TURN IT OFF. This superstitiousness It's not "superstitiousness" when the new features did in fact have vulnerabilities.

eqvinox 2y ago

It's "only" the failure of one layer of security. But also: It's the failure of one layer of security. As much as I agree it's not a big breach, it's not great. Especially if people are aware these profile security features exist, rely on them (maybe more than intended) and then you add a break like this.