15 ms·

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 lev

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?

usrnm 3y ago
You can't limit resources like CPU and memory for users.
- inferiorhuman 3y ago
  https://man.freebsd.org/cgi/man.cgi?query=login.conf&apropos=0&sektion=5&manpath=FreeBSD+13.2-RELEASE&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=login.conf&apropos... https://man.freebsd.org/cgi/man.cgi?query=rctl&apropos=0&sektion=0&manpath=FreeBSD+13.2-RELEASE&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=rctl&apropos=0&sek... https://www.tecmint.com/set-limits-on-user-processes-using-ulimit-in-linux/ https://www.tecmint.com/set-limits-on-user-processes-using-u...
- dijit 3y ago
  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.
  - usrnm 3y ago
    And systemd does the exact same thing under the hood as running in a container would.
- _joel 3y ago
  cgroups?
asah 3y ago
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...
- OlympusMonds 3y ago
  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 https://github.com/SEL4PROJ/imagesh/tree/master
- ndmrs 3y ago
  > 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/ https://www.cncf.io/projects/containerssh/
- mala-2 3y ago
  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.
tyingq 3y ago
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.
- jasomill 3y ago
  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.generator.html 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.unit.5.html https://docs.podman.io/en/latest/markdown/podman-systemd.uni... [3] https://github.com/containers/podman/blob/6ab38e55e733e70c9592ce41132a0f390b236560/pkg/systemd/quadlet/quadlet.go#L316 https://github.com/containers/podman/blob/6ab38e55e733e70c95... [4] https://www.freedesktop.org/software/systemd/man/systemd.timer.html https://www.freedesktop.org/software/systemd/man/systemd.tim... [5] https://docs.podman.io/en/latest/markdown/podman-run.1.html#systemd-true-false-always https://docs.podman.io/en/latest/markdown/podman-run.1.html#...
gnufx 3y ago
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.
curt15 3y ago
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.

usrnm 3y ago

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

inferiorhuman 3y ago
https://man.freebsd.org/cgi/man.cgi?query=login.conf&apropos=0&sektion=5&manpath=FreeBSD+13.2-RELEASE&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=login.conf&apropos... https://man.freebsd.org/cgi/man.cgi?query=rctl&apropos=0&sektion=0&manpath=FreeBSD+13.2-RELEASE&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=rctl&apropos=0&sek... https://www.tecmint.com/set-limits-on-user-processes-using-ulimit-in-linux/ https://www.tecmint.com/set-limits-on-user-processes-using-u...
dijit 3y ago
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.
- usrnm 3y ago
  And systemd does the exact same thing under the hood as running in a container would.
_joel 3y ago
cgroups?

asah 3y ago

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...

OlympusMonds 3y ago
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 https://github.com/SEL4PROJ/imagesh/tree/master
ndmrs 3y ago
> 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/ https://www.cncf.io/projects/containerssh/
mala-2 3y ago
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.

tyingq 3y ago

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.

jasomill 3y ago
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.generator.html 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.unit.5.html https://docs.podman.io/en/latest/markdown/podman-systemd.uni... [3] https://github.com/containers/podman/blob/6ab38e55e733e70c9592ce41132a0f390b236560/pkg/systemd/quadlet/quadlet.go#L316 https://github.com/containers/podman/blob/6ab38e55e733e70c95... [4] https://www.freedesktop.org/software/systemd/man/systemd.timer.html https://www.freedesktop.org/software/systemd/man/systemd.tim... [5] https://docs.podman.io/en/latest/markdown/podman-run.1.html#systemd-true-false-always https://docs.podman.io/en/latest/markdown/podman-run.1.html#...

gnufx 3y ago

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.

curt15 3y ago

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.