I’m new to the container world. Does it have any security benefits when I run my applications as a non-root user in a docker container? And how about Podman? There I’ll run the container as an unprivileged user anyway. Would changing the user in the container achieve anything?

  • sudneo@lemmy.world
    link
    fedilink
    English
    arrow-up
    19
    ·
    8 months ago

    tl;dr, yes, it does.

    Containers are nothing like VMs, and containers in Linux are basically a combination of a feature called Cgroups, which allows to restrict the resources (like memory, etc.) available to a process or group of processes, and namespaces. Namespaces are a construct in which certain namespaced resources are separated from each other, and processes can only see those belonging to their namespace. A simple example is a mount namespace. When you launch a container, you see a / directory which is not the root directory of your system.

    Now, the problem is, that not all the resources are namespaced, so there is still quite a lot that processes within containers can do interacting with the main system resources, especially if they are root.

    A root process within a container generally can do lots of things that the actual root process can do outside of it. For example, mounting parts of the filesystem (if you run with --privileged), loading kernel modules, etc. Podman can run rootless, in the sense that it uses also User namespaces, meaning a user 0 (root) inside a container is actually mapped to something else outside, but also docker nowadays can do the same.

    So yeah, in general, running the applications with the less amount of privileges is a good idea and you should do it whenever you can. Even if you do need some privileges, you should add only the Capabilities needed, not just go straight to root.

  • ck_@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    3
    ·
    8 months ago

    Container are not a security concept. Hence, running things inside of a container does not provide any security benefits as opposed to outside of the container.

    In actual fact, if you take the time to configure you services with proper systemd security features, you get more secure environments than with running generic containers with “just” unprivileged users.

    • sudneo@lemmy.world
      link
      fedilink
      English
      arrow-up
      9
      ·
      8 months ago

      Not really true, containers are based on namespaces which have always been also a security feature. Chroot has been a common “system” technique, afterall.

      Containers help security if built properly, and it’s easier to build a container securely (and run them), compared to proper SystemD unit security.

      • ck_@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        1
        arrow-down
        6
        ·
        edit-2
        8 months ago

        containers are based on namespaces which have always been also a security feature.

        Incorrect.

        Chroot has been a common “system” technique, afterall.

        Incorrect.

        • sudneo@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          8 months ago

          OK :)

          So chroot has not been used to isolate processes for decades to a confined view of the filesystem (especially in combo with a restricted shell), and for example the networking namespace is not used to limit the impact on a compromise on the firewall, the user namespace is not used to allow privileged processes to run de-facto unprivileged.

          Whatever you say

  • x1gma@lemmy.world
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    4
    ·
    8 months ago

    Imagine your containers as very lightweight mini-VMs. Would you run everything as root in your virtual machines? Containers aren’t really that different to classical VMs from an operations point of view. You have a different attack surface, but it is still there, and running as a non-root user inside the container reduces this attack surface, and should IMHO be the default. Privileged containers and users may be required for specific purposes, but should not be the norm, if possible.

    • ck_@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      12
      arrow-down
      3
      ·
      8 months ago

      This comment shows misunderstanding of what container and virtual machines are and how the technology behind each concept works. Containers are NOT virtual machines, do not treat them as such.

      • x1gma@lemmy.world
        link
        fedilink
        English
        arrow-up
        5
        arrow-down
        1
        ·
        8 months ago

        You’re right, containers are not VMs, and I’ve never claimed that. For the matter of basic unix access control for a beginner they are similar enough to treat them as such. It’s enough of a baseline for basic security for a beginners workload imo. For advanced use cases - absolutely do not treat containers as you would VMs.

  • loudwhisper@infosec.pub
    link
    fedilink
    English
    arrow-up
    2
    ·
    8 months ago

    I have seen this post and decided to respond via a separate blog post. https://loudwhisper.me/blog/containers-isolation/

    The short answer is that yes, they do. And yes lowering the privileges of the user helps in avoiding container escapes, which basically makes the other advantages for containers valid. You can, however, achieve the same using (relatively obscure, imho) systemd settings, running with flatpak etc. Namespaces + Cgroups + Seccomp + Capabilities = better security. Containers make it easy to use all of the above.