1. Forum
  2. Usenet
  3. LINUX.DEBIAN.KERNEL

  • Re: Bug#1012547: linux: disable user namespaces per default

    From mikoxyzzz@gmail.com@21:1/5 to philcerf@gmail.com on Tue Jul 19 12:40:01 2022
    On Tue, 5 Jul 2022 at 16:22 Philippe Cerfon <philcerf@gmail.com> wrote:
    Say welcome to CVE-2022-32250, the next root security hole which
    would
    apparently have been mitigated if Debian were to ship sane defaults.

    I'm sorry that you didn't read the actual CVE. This wasn't a bug with
    user namespaces, but rather a bug in netfilter that was exploitable
    through user namespaces. Of course, this wouldn't really have been
    exploitable had user namespaces since root using an exploit to elevate
    its privileges to root is... silly. The bug would've still existed
    without user namespaces, which is still bad, it just would've been
    pointless.

    It's pretty funny, actually; from what I'm able to undertstand, most,
    if not all the CVEs you listed in your original report weren't really
    bugs with user namespaces *at all*, they were really just bugs in
    components *around* user namespaces. Instead, how about we disable
    netfilter et al. for being buggy? ;)

    I really don't think the morale of the story here is "user namespaces
    are dangerous", but rather "code in Linux tends to be buggy and should
    be
    fixed", and I don't see why user namespaces should be disabled when it's
    other components that are buggy dangerous.

    Do correct me if I'm wrong, though.

    --
    ~miko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philippe Cerfon@21:1/5 to mikoxyzzz@gmail.com on Wed Jul 20 04:30:01 2022
    On Tue, Jul 19, 2022 at 12:20 PM <mikoxyzzz@gmail.com> wrote:
    I'm sorry that you didn't read the actual CVE.

    Well I did... which is why I haven't written "the next security hole
    in user ns" but "the next one that have been mitigated if Debian were
    to ship sane defaults".


    Do correct me if I'm wrong, though.

    In the end of the day it's still yet another root security hole which
    was exposed for no good reasons, by user names being enabled per
    default - where the bug originates in, won't really bother any
    attacker, nor will it make a difference for any compromised system.

    Regards,
    Philippe

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gregor Riepl@21:1/5 to All on Thu Oct 27 13:40:01 2022
    Seems I'm not the only one who's quite concerned about the ongoing
    security impact of user namspaces, as the recent/current discussion
    about some LSM patches for 6.1 shows:

    99% of all code does NOT WANT the user namespace thing, and it's been
    a big new attack surface for the kernel getting things subtly wrong.

    It's still a shame to see that Debian intentionally sacrifices the
    security of *all* users just for the needs of very few.

    I'd very much like to see where Linus gets his "99%" from. Sounds a like
    like a "I'm not using it, so 99% of all users aren't using it". Podman certainly supports and uses them, when run as non-root. [1] [2]

    The whole point of user namespaces is to *reduce* the attack surface,
    not increase it. If you don't have a comparable feature, you need to
    give your applications more power, increasing the risk of system
    compromise overall.
    For example: Running containers or container runtimes as root.

    That the implementation has serious issues like this one is sad, but it
    is more of an indication that the feature wasn't quite ready for general consumption yet, not that it's a bad feature per se. And how would you
    build a user base and discover issues without making the feature
    available to the general public?


    [1] https://medium.com/techbull/what-is-user-namespace-and-podmans-rootless-containers-fc4c292c6bad
    [2] https://opensource.com/article/18/12/podman-and-user-namespaces

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)