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?
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.
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.
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
EDIT:
Actually, if you are really convinced of what you are saying we can do the following experiment:
We spin up a VPS and run a web application with a RCE with a Systemd unit and run the same web app in a scratch container running under an unprivileged user
Then we can compare the kind of impact that using containers to wrap applications has on the security of the system. My guess, even with a full RCE you will not be able to escape the container.
Half-jokes aside, my stance is that isolation (namespacing and cgroups) allows to greatly reduce the attack surface and contain the blast radius of a compromise, which are security benefits. You can easily have a container with no shell, no binaries at all, no writable paths, read-only filesystem etc. You can do at least some of those things even in a regular Linux box of course, but it is much more uncommon, much harder, much less convenient (for example, no writeable /tmp is going to break a lot of stuff), much more error prone, etc.
Your stance i.e.:
running things inside of a container does not provide any security benefits as opposed to outside of the container
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
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.
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.
Incorrect.
Incorrect.
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
EDIT: Actually, if you are really convinced of what you are saying we can do the following experiment:
scratchcontainer running under an unprivileged userThen we can compare the kind of impact that using containers to wrap applications has on the security of the system. My guess, even with a full RCE you will not be able to escape the container.
Half-jokes aside, my stance is that isolation (namespacing and cgroups) allows to greatly reduce the attack surface and contain the blast radius of a compromise, which are security benefits. You can easily have a container with no shell, no binaries at all, no writable paths, read-only filesystem etc. You can do at least some of those things even in a regular Linux box of course, but it is much more uncommon, much harder, much less convenient (for example, no writeable /tmp is going to break a lot of stuff), much more error prone, etc.
Your stance i.e.:
is way too absolute, imo.
[citation needed]