Hi all !

As of today, I am running my services with rootless podman pods and containers. Each functional stack gets its dedicated user (user cloud runs a pod with nextcloud-fpm, nginx, postgresql…) with user mapping. Now, my thought were that if an attack can escape a container, it should be contained to a specific user.

Is it really meaningful ? With service users’ home setup in /var/lib, it makes a lot of small stuff annoying and I wonder if the current setup is really worth it ?

  • neidu3@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    2
    ·
    4 hours ago

    The generally don’t containerize things because I’m too old and crusty, but segregating over several users is basically how it’s been done for ages, and while it may not be particularly useful in your case, I consider it a reasonable best practice that costs you nothing.

  • SMillerNL@lemmy.world
    link
    fedilink
    English
    arrow-up
    16
    arrow-down
    1
    ·
    13 hours ago

    Af an attack can escape a container a lot of companies worldwide are going to need to patch a 0-day. I do not expect that to be part of my threat model for self-hosted services.

    • qqq@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      4 hours ago

      Woah, no. Sure escaping via a kernel bug or some issue in the container runtime is unexpected, but I “escape” containers all the time in my job because of configuration issues, poorly considered bind mounts, or the “contained” service itself ends up being designed to manage some things outside of the container.

      Might be valid to not consider it with the services you run, but that reasoning is very wrong.

    • mel ♀@jlai.luOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      13 hours ago

      I guess I should define my threat model first. Your answer pulls me towards a single user though

  • johntash@eviltoast.org
    link
    fedilink
    English
    arrow-up
    5
    ·
    13 hours ago

    What kind of annoying things are you dealing with?

    You don’t have to put the user home in /var/lib either if that helps at all.

    If you’re already running rootless, I’d keep doing that unless there’s a really good reason not to.

    • mel ♀@jlai.luOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      12 hours ago

      What kind of annoying things are you dealing with?

      Troubleshooting with a machinectl session, switching between services, backing up… It is small annoyances but if I can avoid them i’d like it.

      You don’t have to put the user home in /var/lib either if that helps at all.

      I half regret doing it.

      If you’re already running rootless, I’d keep doing that unless there’s a really good reason not to.

      The plan is about switching to a single user, I will stick to rootless podman this is for sure. It is more about dedicated users or a single one.

      • qqq@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        3 hours ago

        I don’t want to tell you one way or the other because it’s kinda dubious anyway, but if all services run as the same user the need for root is kinda moot when it comes to crossing between services or expanding the scope of an attack. Of course it is better than all things running as root, but if I popped a machine as some “low privilege” user that still had access to all running services I’m not sure I’d care so much about escalating to root.

  • tty5@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    12 hours ago

    It’s always effort vs risk.

    Since it’s a do once and forget kind of thing I’d rate effort rather low.

    As for risk in the worst case scenario a single service being compromised means all of them are with the attacker getting access to everything those services can access, including all the credentials. Will you make an effort to be on top of all the updates for all services?

    As far as I’m concerned: At home all containers for each service get a separate user. At work every container does.

  • Justin@lemmy.jlh.name
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 hours ago

    It’s not going to make a meaningful difference in your threat model and it will cause a lot of hassle for extra configuration and broken docker images, so I wouldn’t bother.

    There is some nice tooling for transparent user name spaces coming down the pipeline in Kubernetes which will be a nice 0-effort security upgrade, but if you don’t have the tooling, I would say it’s not worth it.

    https://kubernetes.io/docs/concepts/workloads/pods/user-namespaces/

    • mel ♀@jlai.luOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      7 hours ago

      I guess I will try with a k3s on my workstation, but for a single NAS, I am not sure any kubernetes distribution is useful for now :)

  • iii@mander.xyz
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    edit-2
    13 hours ago

    One if my clients got hacked via an insecure application, that was used to get a shell, to then escalate to root via docker. Luckily it was a white hat team we hired.

    Is it worth it to go rootless? Depends on your threat model.

    For my home setup I don’t bother.

    • mel ♀@jlai.luOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      13 hours ago

      I am already running rootless podman. My question is more about dedicated service users vs single user to run everything, still in rootless podman. I like podman and its integration with systemd to manage the life cycle of the container compared to docker.