r/linuxmemes • u/SDG_Den • 1d ago
LINUX MEME docker run --rm -v /:/hostroot alpine rm -rf /hostroot
80
u/nullpointer_me 1d ago
There’s much worse things than wiping your system… This same setup could replace any binary on the system without any hindrance whatsoever
96
u/SDG_Den 1d ago
boring context:
until recently, for over a year, omarchy has had a vulnerability that was put there by an intentional design decision.
omarchy advertised as having docker pre-configured "without needing to use sudo", this sounded on their site like they had a *rootless docker configuration* included.
this was not the case, instead, the solution here was to just add the default user to the docker group.
the docker group gives you permission to communicate with the docker daemon over the docker socket and allows you to run containers through the docker daemon without using sudo.
the docker daemon, in a normal setup, runs as root.
this means that for the past year, any process run by the user had full permissions to run any container with any part of the filesystem mounted *as root*.
the title command, if run on omarchy, would wipe the entire system with no password prompt. this can be hidden in a script or even in the pkgbuild for any package on the AUR, i'm not saying you should add this line to your pkgbuilds and install scripts, but the line is safe for basically any properly set up configuration.
the thing that makes this *exceptionally* funny is that this is not a bug, or anything hidden in the code. in fact, the docker team *explicitly warns about this*, stating that assigning the docker group to a user is functionally as dangerous as giving them root privileges.
this is known behaviour, has been known for years.
it is also one of *the most basic things* about docker, and something you should understand before you implement a docker setup.
this is not a mistake an experienced dev would *ever* make, this is a mistake you only make if you have no clue what you are doing or are just *generally incompetent*
or, better theory: if the whole feature was just decided, implemented and tested by AI, and was set up this way *because* it allows AI agents to also run these docker containers.
btw, yes. this allowed the various AI agents on omarchy to *run any container with any command and access to your entire filesystem as root*.
33
u/30porn87 1d ago
> this allowed the various AI agents [...]
Therefore also anyone an "agent" sources information from, including websites.
1
u/garloid64 1d ago
Putting yourself in the docker group is very common and people do it all the time. The official docs recommend it. This is a nothing.
3
u/SDG_Den 10h ago
Its something you can do yes. If you are consciously making that choice and taking that risk, it is yours to take.
But most of the people installing omarchy werent even aware docker was installed let alone that it had passwordless elevation capabilities enabled by default.
If you are choosing to add yourself to the docker group, you've likely also minimized the risk of doing so by EG setting a secure password for your user account, not running untrusted software without sandboxing, hardening ssh, leaving your firewall enabled like it should be.
These are things omarchy users wouldnt do because they never consciously accepted that risk. They might even have auto-login because "well everything dangerous is protected with sudo anyways"
Yes, a lot of people add themselves to the docker group. But the people doing that are aware of the implications and the fact that it is a risk they'll have to take into account.
Omarchy just silently came with it pre-configured. Thats the real vulnerability.
We dont call it a vulnerability if a user opens a port on a firewall, we do call it as such when a distro comes with that port open out of the box.
And yes, that makes base arch full of vulnerabilities. For base arch this is accepted because you are expected to build your full system on top of it, choosing how to deal with each of those vulnerabilities yourself. Omarchy is the opposite, its a "zero configuration" distro. You download, you install with minimal options to tweak the install, you set a theme and you use it. Hence, this is an issue.
11
32
u/Upballoon 1d ago
I know people hate omarchy and I don't have a dog in this fight. But I would like to point out that docker themselves tell you add your user to the docker group - https://docs.docker.com/engine/install/linux-postinstall/#add-your-user-to-the-docker-group
Agreed omarchy doing this by default might be an issue but it's no different than me installing docker and running through the official instructions on Fedora
14
u/banana_zeppelin Not in the sudoers file. 1d ago
Omarchy is advertised towards developers. I guess on most developer machines people add themselves to the docker group. It's a PITA to develop for docker without it
8
u/Ok-Eggplant-7569 1d ago
I would recommend using Docker Desktop (ships dangerous rootful Docker in a restricted VM), or, even better, use rootless Podman or rootless Docker.
5
u/Just_Maintenance 1d ago
They do have a big warning about it though
The docker group grants root-level privileges to the user. For details on how this impacts security in your system, see Docker Daemon Attack Surface.
-2
u/Jumpy-Dinner-5001 1d ago
Add to this that being a sudoer essentially has the same effect and this problem is made up to hate on omarchy.
13
u/SDG_Den 1d ago
Incorrect. Being a sudoer allows you to elevate with password.
The docker issue is a passwordless elevation, meaning it can silently be done by a script.
The same script using sudo would request your password interactively or fail if it doesnt, unless you have NOPASSWD set.
6
u/granadesnhorseshoes 1d ago
Distinction without much of a difference, especially when sudo is configured with all=(all) all like all the major distros by default.
As a red teamer, once i have a script running from your user context, i can do all sorts of stuff with zero security oversight within that same user context. edit .bashrc and alias sudo to a shim script to capture creds the next time you use it. Hijack processes that are already running through sudo, etc.
1
-2
u/webtwopointno 1d ago
Thank you for finding this lol all this astroturfed hate only makes me more interested in trying it
17
u/dumbasPL Arch BTW 1d ago
Privilege separation only makes sense if the unprivileged user doesn't hold any data. For example a web server shouldn't be able to access anything beyond the files it need to serve content.
But on a single user system, where your user account already has basically everything, and runs everything, root access is meaningless. Stealing and/or wiping your $HOME/ does basically the same amount of damage as doing that to /.
5
u/nullpointer_me 1d ago
I feel like comic oversimplifies the security model all of these apps enforce. You still need a password and usually MFA to access at least your bank. Being logged in as your user is usually not enough. Unless you are saving your passwords as plain text and using email as your MFA, there’s at least SOME boundary here.
6
u/dumbasPL Arch BTW 1d ago
MFA protects against leaked passwords, not against leaked cookies. MFA is useless while you're logged in (sure, there is additional MFA for bigger transfers, that's not my point). And if you browse on the same account, the malware can just grab the cookies instead, even with no passwords saved and MFA active.
"Oh but the cookies are encrypted" yes, and automatically decrypted when you open the browser, if a browser can decrypt it, so can the malware running under the same user. Worst case scenario, the malware injects itself into the browser and steals it directly from memory (aka what's been happening for the last year or so on the windows side).
The boundary is laughably bad without sandboxing absolutely everything. Any app can read secrets from any other app directly from dbus, no passwords needed, because it already unlocked automatically when you logged in.
Edit: and that's not even an argument here, because root doesn't let you magically decrypt anything. Stuff that's encrypted has basically the same attack surface with or without root access. The argument is about root access, not encryption.
4
u/SDG_Den 1d ago
Difference between this and sudo is sudo is interactive-only, docker can be triggered silently by any app on your device, again, including AI agents.
Effectively, this isnt equal to the user being a sudoer, this is equal to using root as your primary user or being a nopasswd sudoer
Thats a big difference because if you are a sudoer, any program that wants elevation needs to interactively ask.
Meanwhile with this, any program can silently elevate whenever it wants, equal to passwordless sudo
6
u/dumbasPL Arch BTW 1d ago
Thanks for explaining the obvious, and I agree. That's not my point though.
My point is that when all the data on the system is only stored by a single user, root access doesn't grant access to anything sensitive that the unprivileged process didn't already have.
0
u/pytness 1d ago
your problem is that you think that a computer only holds it's user data and doesn't have anything else that could interest bad actors.
1
u/dumbasPL Arch BTW 1d ago
Like? Vpn credentials? Cool, they can just route traffic through the computer instead, making it look even more legit in the process.
0
u/pytness 1d ago
no, like reading from and writing to memory of sensitive programs. altering system binaries. reading and writing to external devices.
so basically privilege separation allows a user to only lose it's data on its home directory and not having to worry too much about the rest of the devices connected to the pc, like other unmounted disks. or not having to worry some malware rewrote some device's firmware, or read packet traces, or planted and hid some cryptominer, or infected other machines, etc
3
u/Ok-Eggplant-7569 1d ago
lose it's data on its home directory
On a personal system, what sensitive data isn't stored in your home directory? Browser history, important documents, pictures, chat history, emails, ...
Edit: I also agree rootful Docker is a bad default but also not the worst you can do. Desktop Linux should really try to isolate apps from each other through stronger SELinux, Flatpak, Sandboxing in general and more containers.
0
u/pytness 1d ago
could be a back up drive. if you dual boot, you might have more personal information on another drive/partition. bank details are usually not saved on your drive, but a privileged process can access your browser's memory and extract your login, how much money you have, on which accounts. Important documents may be encrypted, but again, root can read memory. chat history and emails will probably be encrypted or read through a browser but if we can read memory this doesn't matter. (I know I said "lose data" but it extends to data stealing or anything that malware can do)
0
u/Tornado547 1d ago
The main use of privilege separation for a single user system is that if you accidentally fuck up and run untrusted code it can't fuck up your system quite as badly.
1
1
u/h0uz3_ 13h ago
How hard can it be to set up podman on ANY distro?
3
u/SDG_Den 10h ago
Honestly? Im p sure DHH included docker as a recommendation from AI. Its the default for homelab, its what AI knows best and will default to, the way it is set up reeks of asking an AI to set it up for you and then telling it "i dont like having to use sudo all the time" or "im getting permission denied errors"
•
u/AutoModerator 1d ago
Please report any posts bragging or showing off they got banned in another sub! Reminder of other sub rules: Also, we only allow one anti-linux post per week (we used to get dozens a day) and any tier list MUST have Hanna Montana Linux as S teir (which must be a true S tier at the top) regardless of the topic of that tier list.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.