Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Podman in Linux

diego-pacheco.blogspot.com

Post reply on HN
Print view View original

31–40 of 90 posts

Re: Podman in Linux

#31

Post by gizdan »

jhickok wrote: post #17
gizdan wrote: post #14

Earlier quoted context omitted.

From what I've seen in all these Podman articles, I've come to the same conclusion as you. This is how Podman fits in: Podman (and its various components) can replace everything but parts of Docker Desktop, namely the GUI that Docker Desktop, has. For everything else, it has it's own Docker compatible CLI, an optional daemon (by default it's daemonless), there is no containerd component as it communicates directly to…

My understanding is that Podman is working on a "GUI" since it is one of the most requested items. Taken from the interview with the founders of Podman over on the Google Kubernetes podcast: https://kubernetespodcast.com/episode/164-podman/ ETA: Oh hey here it is: https://github.com/heyvito/podman-macos

Good to know about the GUI!

> ETA: Oh hey here it is: https://github.com/heyvito/podman-macos

This GUI isn't an official Podman application. It's a third party. Not that it's bad or anything, it's just not official.

Re: Podman in Linux

#32

Post by solarkraft »

kbenson wrote: post #25
Iolaum wrote: post #12

podman user here, because of the ability to run in rootless mode. Using it on RPi4 with Fedora IoT running linuxserver io containers. Appreciate the systemd integration as well making the containers services that gracefully go down and come up when the pi gets rebooted without me needing to do anything.

I was enamored with this feature too, but a comment here on HN[1] made me reconsider its use. Apparently rootless requires unprivileged user namespaces, which provides a different security context than most apps are expected to run in, and might be less thoroughly tested than you would think. I still like the systemd integration and that it doesn't require a daemon too, and I still favor it over Docker. 1: https://ne…

Thanks for linking the original comment. Every container uses namespaces, this is (TL;DR attempt) about user namespaces, which is a not particularly well audited kernel feature, meaning you may open up potentially insecure kernel code to unprivileged users.

The way I understand it, with containers running under a root user, is that to break out of a container you‘d have to find a vulnerability in standard (rootful) namespaces, which is much less likely (since it’s the same thing everything including Docker uses).

Re: Podman in Linux

#33

Post by maxdamantus »

some0x80070005 wrote: post #19
Iolaum wrote: post #12

podman user here, because of the ability to run in rootless mode. Using it on RPi4 with Fedora IoT running linuxserver io containers. Appreciate the systemd integration as well making the containers services that gracefully go down and come up when the pi gets rebooted without me needing to do anything.

It’s great that podman serves a good role for you, and I’m not going to argue that. My points: 1. Docker containers absolutely can be run without root. Yes, it’s not the default policy, but containers can have a user ID. If you are referencing the daemon-less root-less nature of podman, that’s a clear advantage of podman vs Docker. 2. Docker containers also have a restart policy which I use to also have them startup…

Probably worth pointing out that docker has had a "userns-remap" option for quite a while, which causes all containers to run in a separate user namespace where UID 0 inside remaps to something else outside, so theoretically a user with access to the docker daemon isn't able to view the outside filesystem as root[0].

I have gone back and forth with podman. At some point it seemed to sometimes get into a funny state where I would simply delete everything[1] to fix it. On all systems where I run docker, I make sure to have "userns-remap": "default" in /etc/docker/daemon.json. Haven't looked into the rootless mode yet, but I was aware a few years ago that they were working on it.

[0] Without remapping root inside a different namespace, anyone with access to the docker daemon can access the outer root filesystem as root using a command such as `docker run --rm -it -v /:/oops alpine`

[1] Amusingly, the simplest way to do this was by using root to run `rm -rf` on my own ~/.local/share/containers/ directory, since the containers used UIDs other than my own (ones that are part of my subuid range)

Re: Podman in Linux

#34

Post by inetknght »

jrockway wrote: post #23
inetknght wrote: post #10

Earlier quoted context omitted.

cp ./app.AppImage /srv/app/app.AppImage for deployment_host in $( okay boss, what's the next problem?

app.AppImage used up all the RAM on the machine, and the kernel OOMkilled sshd. Now it's time to roll back. (But I guess it wasn't the fault of that deployment -- you just staged the binary, you didn't start it running.)

The app.AppImage is staged to the network share and started on the remote host. The AppImage might eat all the RAM and the AppImage will get OOMkilled but sshd is unlikely to be killed. When the AppImage gets OOMkilled, the ssh session will end with an error and the ssh client will report that the session terminated unexpectedly.

I've done it (and later cringed). But it definitely works.

Re: Podman in Linux

#36

Post by akerl_ »

some0x80070005 wrote: post #19
Iolaum wrote: post #12

podman user here, because of the ability to run in rootless mode. Using it on RPi4 with Fedora IoT running linuxserver io containers. Appreciate the systemd integration as well making the containers services that gracefully go down and come up when the pi gets rebooted without me needing to do anything.

It’s great that podman serves a good role for you, and I’m not going to argue that. My points: 1. Docker containers absolutely can be run without root. Yes, it’s not the default policy, but containers can have a user ID. If you are referencing the daemon-less root-less nature of podman, that’s a clear advantage of podman vs Docker. 2. Docker containers also have a restart policy which I use to also have them startup…

When people talk about “rootless” in this context, they’re not talking about “launching containers whose process runs as non-root”. The innovation of podman is that a non-root user can “safely” be given permission to launch containers whose maximum permissions are “the perms that user has”.

Docker doesn’t have this functionality: the daemon runs as root, and anybody who is granted access to launch containers by invoking Docker commands can inherently access root-level privileges. The most mundane way to do this is to launch a container with the host’s namespaces instead of generating new ones.

Re: Podman in Linux

#37

Post by CameronNemo »

solarkraft wrote: post #32
kbenson wrote: post #25

Earlier quoted context omitted.

I was enamored with this feature too, but a comment here on HN[1] made me reconsider its use. Apparently rootless requires unprivileged user namespaces, which provides a different security context than most apps are expected to run in, and might be less thoroughly tested than you would think. I still like the systemd integration and that it doesn't require a daemon too, and I still favor it over Docker. 1: https://ne…

Thanks for linking the original comment. Every container uses namespaces, this is (TL;DR attempt) about user namespaces, which is a not particularly well audited kernel feature, meaning you may open up potentially insecure kernel code to unprivileged users. The way I understand it, with containers running under a root user, is that to break out of a container you‘d have to find a vulnerability in standard (rootful) n…

But the vulnerability without usernamespaces is much more severe, because the process then has UID 0 on the host.

Frankly if you are that concerned about security (e.g. you have multitenant workloads or are dealing with sensitive data), you should be using KVM or gvisor.

Re: Podman in Linux

#38

Post by CameronNemo »

PhilippGille wrote: post #27
some0x80070005 wrote: post #19

Earlier quoted context omitted.

It’s great that podman serves a good role for you, and I’m not going to argue that. My points: 1. Docker containers absolutely can be run without root. Yes, it’s not the default policy, but containers can have a user ID. If you are referencing the daemon-less root-less nature of podman, that’s a clear advantage of podman vs Docker. 2. Docker containers also have a restart policy which I use to also have them startup…

> root-less nature of podman I see this repeated a lot, but it's not the default, its has to be explicitly configured: https://github.com/containers/podman/blob/v3.3.1/docs/tutori... And in addition to the known upsides, there are some lesser known downsides: 1. There are feature limitations with it: https://github.com/containers/podman/blob/v3.3.1/rootless.md 2. There are security implications, quoting Arch Wiki: >…

Why should I trust the Arch wiki? People like Christian Brauner think the value of not running as UID 0 outweighs the increased attack surface from the user namespace.

https://people.kernel.org/brauner/runtimes-and-the-curse-of-...

Re: Podman in Linux

#39

Post by vngzs »

kbenson wrote: post #25
Iolaum wrote: post #12

podman user here, because of the ability to run in rootless mode. Using it on RPi4 with Fedora IoT running linuxserver io containers. Appreciate the systemd integration as well making the containers services that gracefully go down and come up when the pi gets rebooted without me needing to do anything.

I was enamored with this feature too, but a comment here on HN[1] made me reconsider its use. Apparently rootless requires unprivileged user namespaces, which provides a different security context than most apps are expected to run in, and might be less thoroughly tested than you would think. I still like the systemd integration and that it doesn't require a daemon too, and I still favor it over Docker. 1: https://ne…

I am generally conservative about these things, but recently the consensus appears to be that unprivileged user namespaces are stable enough for GA. If you work in a targeted environment (e.g., you are a reporter covering civil liberties), maybe you should wait a bit longer, but for average people the advantages of rootless containers probably exceed the advantages of keeping the unprivileged_userns_clone code out of your attack surface.

I would encourage most security-conscious users to enable it and migrate to recent podman over using Docker, assuming a sufficiently recent kernel. The latest batch of major Linux OS releases have all enabled kernel.unprivileged_userns_clone, so Red Hat, Canonical et al seem to agree.

For those interested, though, you can read the anatomy of a userns clone() vulnerability here:

https://lwn.net/Articles/543273/

Re: Podman in Linux

#40

Post by kbenson »

CameronNemo wrote: post #37
solarkraft wrote: post #32

Earlier quoted context omitted.

Thanks for linking the original comment. Every container uses namespaces, this is (TL;DR attempt) about user namespaces, which is a not particularly well audited kernel feature, meaning you may open up potentially insecure kernel code to unprivileged users. The way I understand it, with containers running under a root user, is that to break out of a container you‘d have to find a vulnerability in standard (rootful) n…

But the vulnerability without usernamespaces is much more severe, because the process then has UID 0 on the host. Frankly if you are that concerned about security (e.g. you have multitenant workloads or are dealing with sensitive data), you should be using KVM or gvisor.

If you're using user namespaces and allowing a previous root only API to be used by a user, it's possible that some escape in that which provides root access (which wouldn't be as huge a deal if it was only ever able to be run as root) allows root level escalation outside the container.

That intermixes with security concerns about what's possible if running as root directly in different ways, and be more or less problematic than a root container depending on the use case, and also more or less likely based on how well those APIs are exercised for the specific use case.

It's not that these should be avoided, it's just that people should be aware that it's not necessarily a pure security increase at the expense of a bit of extra CPU due to kernel checks. There's a bit to consider. Maybe later everyone will consider this tested enough that's it's mostly a pure win. Maybe it's already at that point but people haven't internalized it. I don't know enough to know what stage we're at, but I thought it was worth mentioning, as it took me by surprise when I learned of it.

Post reply on HN