3 ms·

Yikes... are other popular distros shipping with unprivileged user namespaces enabled by default?

• galangalalgol 3y ago
  That is part of enabling rootless containers on rhel or similar.
  • waynesonfire 3y ago
    should have re-written it in rust.
    • yjftsjthsd-h 3y ago
      Rewritten what? The container runtime will need the same access regardless of what it's written in, and rewriting all of Linux (the kernel) would be... ambitious, although it is adopting rust incrementally.
      • scns 3y ago
        The good old Strangler Pattern. https://martinfowler.com/bliki/StranglerFigApplication.html https://martinfowler.com/bliki/StranglerFigApplication.html
        • galangalalgol 3y ago
          Some of the issue though is that a monolithic kernel provides more access than necessary to many things. When they made the locks granular, those might be reasonable boundaries for permissions? At this point I'd rather figure out how to make windows drivers work in redox or something crazy like that.
• failsecure 3y ago
  Yes and this decision haunts distros like Ubuntu over and over again. There's no easy win though.
• marcthe12 3y ago
  Most, I think Debian has patch to be disabled at runtime via sysctl. The reason is that most containers or sandboxing techniques are root only unless you mix it with user namescapes. So most container or sandbox software use suid(firejail) , root daemon(docker) or user namescapes (podman and flatpak). Looking at the cves, user namespaces is probably the safer option
• touisteur 3y ago
  Do you need a user namespace? I'd expect a network namespace to be enough. Am I missing something? Edit: should've read better, this seems to need CLONE_NEWUSER.
  • jwilk 3y ago
    You need CAP_SYS_ADMIN to create a new network namespace.