this post was submitted on 14 Oct 2023
51 points (94.7% liked)
Linux
46734 readers
2108 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Yep, pretty much. I mean I guess it makes sense for containers because the only thing running there is that app anyway, although most good containers set up their own user. For example, the
node
container has anode
user with ID 1000 which is more typical for Linux systems. Docker in particular is often used by Windows/Mac users that aren't necessarily familiar with the ins and outs of Linux and just want it to work, which in a container, is usually fine. With rootless containers, even root in the container is basically useless anyway because it truly runs as a fake ID on the host.But yes, even in the Linux circles, there can be dubious advice or just bad habits. The thing with doing things right is it takes a lot of time, and sometimes, you really just want to make it work. Just look at how many people just
sudo whatever
whenever they get a permission error instead of getting into udev rules or whatever. Especially with the growing interest in Linux thanks in huge part to Valve and Proton, I've seen very dubious habits of "just make it work" being ported over from Windows. Those guides are appealing too: one will give you 3 sudo commands, the other will do it proper but then you have a dozen commands or two to set up users and grant permissions and whatnot. The second guide, although the better one, isn't as appealing as the first one especially when you're lost, you just want the thing to work, and you're looking for simplicity.For a lot of simple use cases, dropping privileges to nobody is simple and easy, no need to create new users. It's not horribly insecure and it's better than root/your own user in terms of blast radius. If there's just one service occasionally running as nobody, it's really no big deal, you just shouldn't run everything as nobody. Plus, people have the tendency of not reevaluating their problem when it grows, so it may start with a simple web server that doesn't need anything, but then you start needing to do more, and the "run the web server" part is mentally marked as done and final, so people will start granting nobody access to more things instead of taking a step back and reevaluating and upgrading their service to a dedicated user with dedicated privileges. Then that leads to privilege creep for a user that's supposed to have none.
The main issue with running more than one thing as nobody is, on Linux, users have the ability to debug their own processes. So maybe your app running as nobody gets exploited, but since you also run NGINX as nobody, now they can hook NGINX and dump TLS certs from it even if the actual files are owned by root and it dropped privileges: it still needs to have it in memory to operate, it loads the certs as root then drops privileges.
That was masterfully explained. Once again, thanks a lot.
I've seen this repeated a lot, but I'm not really convinced running as root inside containers is a good/safe thing to do. User namespaces can provide some protection for the host, but that does nothing for the rest of the files inside the guest. For example, consider a server software with an arbitrary file write vulnerability. If the process is running as a low privilege user, exploiting the vulnerability might not really get you anywhere. If it's running as root, it's basically a free pass to root privilege and arbitrary code execution within the container.
That's why I mentioned rootless containers specifically. In those, root is at most the user running the container. It can't do a whole lot, because it's not really root. Each user in
/etc/subuid
gets a range of dummy IDs >65535 specifically for containers for that user. When outside the container, everything shows as owned by the user, so root in the container can't even result in root owned files on the host, so no suid trickery or anything.Of course you should still run as a user in the container too, I was just pointing out in rootless containers the blast radius is much reduced because of that feature. Definitely still don't want root for many other reasons.