Hacker News Reader

Comment by DangitBobby | Hacker News Reader

Can any grey beard types explain to me why someone would throw users into containers instead of their own user accounts with permissions? Why is the desired level of isolation not possible or too difficult without them?

View on HN

The regular shell is a huge attack surface, including user-to-user attacks and overly permissive network access.

Frankly, ssh-to-container is a "slaps forehead" obvious solution and I'm surprised none of us thought of it before - I'd love to see it as a standard option in the OS, e.g. chsh allows you to specify a container and optional port and volume mappings.

In the old days, we'd (try to) use chroot, but that has all sorts of big problems with needing access to various directories, and those batches begat patches...

We replicated the behavior (somewhat) of the article, using podman, as a way to allow devs to SSH into a container that was identical to the CI/CD environment. It also mapped in their NFS home drive, so they could quickly SSH into the container to try a build, to see if it was their dev machine, or a real issue. It did allow them to choose their container though.

https://github.com/SEL4PROJ/imagesh/tree/master

> Frankly, ssh-to-container is a "slaps forehead" obvious solution and I'm surprised none of us thought of it before

I think CNCF is at the point where you can assume that "there's a CNCF project for that" is true for anything container/kubernetes related.

https://www.cncf.io/projects/containerssh/

I'm not sure if the attack surface is effectively reduced with the use of cointainers. Of course, the user is now in his own namespace, but in order to achieve this, an additional file system, another network interface and a container runtime have been added, thus effectively doubling the complexity. Containers are great if you want to present a service to the outside world or if you want to set up a clean workspace locally. But I wouldn't be comfortable with the thought of letting someone I don't trust into the server behind the firewall. Depending on the configuration, you can reach other local containers via localhost:${port}. An with overlayfs there was afaik a case where you could actually access restricted areas of the underlying filesystem.

These arguments are painting a bike shed: the attack surface is not zero but it's still dramatically reduced and controlled. Nobody said anything about "letting someone I don't trust into the server behind the firewall" which of course is (cough) "not best practice."

Also, containers mean that one user can make changes (install/upgrade software, etc) and not adversely affect another user (incl their security stance).

Since most package managers only support installing software system-wide, users need to compile whatever additional software they need in their home directory and hope that the prerequisite toolchains are already installed by their system administrator. Isolating users in containers allows them to customize their environment via `sudo [apt/yum] install` just like they would on their own computer without affecting other users. Containers can give each user apparent sudo powers while confining all of their operations to their own sandbox. They are a lighter-weight alternative to allocating a full VM to each user.

Not sure. When the shared hosting pattern was popular, it needed to support the users running background daemons that ran all the time, plus things like "cron" and "at", etc. It's not very clear, but the article reads like none of that would work.

Podman installs a systemd generator that automatically transforms the name.container files shown in the article into ordinary systemd user service units[1][2][3], so

    loginctl enable-linger USER

(run once, as root) should cause USER's podmansh container to start as soon as the system enters multi-user mode, independent of USER's login sessions, allowing persistent daemons, including those necessary for job scheduling, namely…

Ordinarily, users can create systemd timer units[4] to schedule at- and cron-style jobs; I assume you need to run a systemd instance inside each user's podmansh container to allow users to create systemd units in the present containerized context (running systemd inside a container is explicitly supported by podman[5]).

If your users don't like systemd, you can also run traditional atd/crond daemons in user containers.

[1] https://www.freedesktop.org/software/systemd/man/systemd.gen...

(This is the same mechanism that, e.g., automatically creates systemd mount units for mounts defined in /etc/fstab.)

[2] https://docs.podman.io/en/latest/markdown/podman-systemd.uni...

[3] https://github.com/containers/podman/blob/6ab38e55e733e70c95...

[4] https://www.freedesktop.org/software/systemd/man/systemd.tim...

[5] https://docs.podman.io/en/latest/markdown/podman-run.1.html#...

There are PAM croup and namespace modules to limit resource use and isolation on Linux-based systems. Obviously they're using the same bases as containers.

You can't limit resources like CPU and memory for users.

https://man.freebsd.org/cgi/man.cgi?query=login.conf&apropos...

https://man.freebsd.org/cgi/man.cgi?query=rctl&apropos=0&sek...

https://www.tecmint.com/set-limits-on-user-processes-using-u...

As much as I complain about systemd being overly complex and the lock-in that follows:

    sudo systemctl edit --force user-1234.slice

    [Slice]
    MemoryMax=1G
    CPUQuota=10%

It's also something that's been available on the other UNIX-likes (FreeBSD/Solaris) since essentially forever.

And systemd does the exact same thing under the hood as running in a container would.

cgroups?

Reply on news.ycombinator.com