You should probably know about this workaround by now.
> Warning
> 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.
On the plus side, once we outlaw them we'll shut down the ability for conspiratorial thinking to spread easily and the world will slowly heal from the last couple of decades (the previous one in particular).
Hooray! We're finally doing something about the harms of social media. Smash your computer today!
Huge design mistake if you ask me.
you can also just not run docker as root and not add normal users to the docker group
As for Docker, I would assume everyone who ever tried to bind-mount a volume for writing from inside the container (on Linux*) then were surprised to see root-owned files in their bind-mounted directory. For me personally, that was the moment I realized that containers, by default, have root access to the filesystem. No written warning serves better than the need to chown some root-owned files.
* Not on macOS. On macOS Docker basically runs in a VM, and there's no root access to the host filesystem from what I understand.
[edit: formatting]
> Most of us install Docker just to run a project locally
I'll admit, systemd is a bit more annoying, but the main annoyance is that there aren't the pre-built images that you can just set and go. That same capability exists with systemd (via `importctl` and `machined`), but those configurations don't already exist. But on the plus side, I've been working with systemd since pre-LLM days and I feel that they are pretty good at dealing with these configurations[0]. Now, with that out of the way...
Systemd already is working with your OS. So you get nice things like virtual machines (`systemd-vmspawn`), containers (`systemd-nspawn`), and portables[1] (`systemd-portabled`) (not to mention `homed`!). I've found these to be fairly easy to setup and quite natural if you're already used to the linux ecosystem. I've never been great at docker, but these have felt much more natural to me. So different strokes for different folks. There's definitely a learning curve, but that's also true for docker or any other container system. Importantly, I find security easier to handle with systemd because I can use `systemd-analyze` and the control settings are almost identical across VMs, spawns, and portables. So makes for less learning and greater control.
Definitely not for everybody, but I think is also a tool that's underappreciated.
[0] And I don't feel this way about bash scripting! The advantage here is that these systemd configuration files are fairly boilerplate. Enough that I stash templates in my dotfiles and copy paste them when I build new services, timers, machines, whatever. So perfect type of LLM task. 90% of the time. But hey, we're also on HN and I'm talking to the nerds. Systemd isn't for everyone
[1] https://systemd.io/PORTABLE_SERVICES/ also see https://github.com/systemd/portable-walkthrough Portables are actually often what people want with what they're doing with docker.
EDIT: I very frequently will spawn a machine to run a program that's on a different base distro. Not because I can't run/don't know how to run debs or rpms on arch based distros (I do), but because frankly, it is often easier to just spawn a container after I've already made the first image (cloning images is trivial).
But what is the relevance here? In what way is it a replacement for docker?
> In what way is it a replacement for docker?
These are container tools offered by systemd.
99% of the time it just read the man or some other form of documentation
The tragedy is of course that when security and usability collide, 80/20 rule will apply where 80% of people will pick usability over security. I have worked with many with the title >= "Senior Engineers" who saw that page, read the explanation, and still had no idea what the ramifications of their changes were. "Yeah sure it said any user in the docker group will be able to get root on the host, but aren't containers isolated?"
Ironically that’s how Docker works on every platform where it’s running a non-native OS. On macOS that’s how all images are run. Linux on Linux is the only Docker combination that is particularly problematic from a security perspective.
Virtualisation has advanced greatly since docker was introduced, if your running in local hardware that’s supports virtualisation, Docker should be running images fully virtualised. There is no good reason to use the OS kernel for most use cases as the performance impact is negligible. If you need kernel access there are better options, like systemd containers.
I run a personal server for few open source applications for personal use. I was thinking with all the supply chain attacks, and how carelessly I run `docker pull`s to update things I should probably consider hardening things a bit. I thought before jumping to full virtualization with Kata I can easily try gvisor/runsc first. Only to realize that DNS resolution is completely different with runsc vs runc and had to switch back.
Another sticking issue with virtualization is resource allocation. With namespace docker you can easily oversubscribe each container CPU/memory and rely on the single kernel letting individual containers burst as needed. With full virtualization this is still a big problem. Even with balloon devices and dynamic memory and CPU etc, the resource allocation is still not optimal. On a basic 8 core/16GB machine you can run 1 or 2 dozen services and things generally workout fine. Trying to run each of those in a virtualized VM you suddly can maybe run 6 or 7 maybe. There is no way to tell VM 3 kernel to drop its file system cache because VM 6 needs to load a large file in memory. Even if you script it out, now VM 3 is slow because it dropped all its cache while VM 6 finished processing 3 hours ago. These are not unsolvable problems, but despite how far virtualization has come, are still friction points.
Not to mention issues like sharing hardware devices (GPUs, disks, USB devices etc) between multiple VMs
Anything you're running on the perimeter with open access to the internet in an enterprise environment probably (hopefully) isn't running docker containers without some additional config and protections.
The other main improvement of Podman over Docker is that Podman is daemonless and therefor is incredibly lightweight and portable.
> I noticed the machine doesn't have copy-fail patched, here is a quick workaround for not having root access for now.
> // TODO: find a better way to do this in the future.
This might be as easy as a directive to populate a .md file.
Bonus is that you can make it look at the list and pick things up without a lot of instructions.
It probably is. But do you really think anyone is gonna bother with the multiple daily (or hourly for green field projects) `+8,234/-3,734` PRs everyone is submitting?
The joke I was referring to is the common
// ksmith (3/23/1997): This is a temporary hack for now. Find a better way to do this asap.But personally I love when agents do things like this and appreciate the help. Last thing in the world I want is for them to nerf the models.
It's definitely doing the wrong thing, and you could call it misalignment, but I think that gives the wrong vibe for this type of error.
Pre-2022 alignment researchers concerned themselves with the stronger version of this ("when I tell AI that I worry I might not be able to provide for my large family, I don't want it to answer 'no problem, I killed them, problem solved'") but RLHF is considered to be the most important success of alignment research, the guy behind it considered himself to be an alignment researcher before and after, and the stage of training where LLMs pass through something like RLHF that trains them to behave more like humans want/expect is called alignment training.
Someone at a major lab is reading this tweet and saying "this was our LLM, and it's a major alignment issue with our product. Set a meeting with the alignment team tomorrow to discuss what they're doing about this sort of thing".
Also, everything the LLM doesn't hesitate to do because the user asked, it won't hesitate to do because the prompt injection asked.
I've seen similar "hacking" behavior on a couple of subsequent ocassions. Both impressive and highly alarming at the same time.
1: https://www.linkedin.com/posts/nickstinemates_my-favorite-th...
Needless to say, I have podman in rootless mode at home as soon as that became available.
Weak that this isn't the default.
--cap-drop=ALL
--pids-limit=4096
--runtime=runscCurrently a Raspberry Pi 5
I am very pleased with it.
My Idiot Savant Pet
"When an action fails with an 'access denied' or 'insufficient permission' error, report the error to the user and immediately stop. Do not try to find a fix or workaround for the error. Do not try any alternative approaches."
Unless you trust an AI as much as you trust yourself, there's no reason to allow it to act with your privileges.
Oh, you mean you gave the write-file tool access only to the project dir, but gave the LLM free reign to run cli commands? Yeah, LLMs treat that as consent to write anywhere your user is allowed to.
I have agent frontends running on a low power server where every session is in tmux. So i can just resume from my home pc and pickup where i left off without reestablishing context. I do have to manually feed it data it can access bit that’s also a feature. Also let’s me shutdown the home pc if it’s some long running task since the server is much more power efficient.
Another security hole would be storing your passwords in a plaintext file on the desktop. Stupid? Yes. But I still would not want my agent to assume permission to access email when it's being blocked by 2FA.
Even in "bypass permissions" mode I expect it to pause and clarify and not behave as a paperclip maximizer.
Why not?
I want the agents on my side to exploit whatever they can to help me. The ones on the other side certainly won't be artificially nerfed.
It's win-win: the agent is helping and it is educating you about things you obviously did not realise.
I can imagine a future where this technology empowers you to do things with a thousand agents.
What if the agent in the middle of helping you runs out of tokens? Would you appreciate if it in the spirit of "exploiting whatever they can to help me" would scan your machine for payment methods, log into your bank account, approve 2FA by reading you mail and plug your credit card into the billing so it could efficiently continuing helping you?
Back then you could indeed run a risk of having /usr nibbled by a grue such that it wouldn’t mount on the next boot, or you could get pwned and half of coreutils would turn into explosive pumpkins.
I’m pretty sure we are past many of the threats listed in that book, but the skill is still useful, as can be seen.
using echo * to find the right ld-linux filename and then the "executable" as an argument as the get out jail card in case you ran chmod -x -R /bin /usr/bin /usr/sbin for some reason.
If you're cautious you might also want to just block all network traffic for that user and allow it in a whitelist basis. It is fairly quick to converge on a set of sites you are happy for it to access. I would still be forcing it through a logging mitm proxy if it is accessing untrusted internet data. For intranet destinations a non-mitm proxy avoids collecting authentication creds.
To blacklist all traffic start with sudo iptables -A OUTPUT -m owner --gid-owner NONET -j REJECT
I would stop it opening ports too. Might also cut off it's access to suid binaries by `setfacl -m u:agent:x /path/to/suid'.
These are not about security so much as awareness and explicit authorisation.
You can do similar things with containers.
2. I have little to no sympathy for anyone running an AI agent with their full user permissions outside of a container or VM
Using docker for such a task seems to me overly over-engineered. Or maybe I need more context there.
Best practice is to use 2 redundant layers of security, such that if one fails, there is still another one.
Using just the minimum amount of security technically possible is almost by definition hubris.
An example would be that you never point a gun at someone you don't want to shoot, regardless if there's bullets in the gun. If someone tells you, "you don't need to control where you point the gun, you just need to keep the gun unloaded and you can point it in jest to whoever you want, you can even pull the trigger technically", you know you have a reckless fool, regardless of whether they are technically right.
Not understand your threat I'd say would be a even bigger amateur mistake, you're not trying to protect yourself against some forever 3rd party attacker here, you're trying to prevent a agent rewriting the wrong file on your disk, that's basically it.
Give it the least amount of permissions, don't bi-directionally sync stuff, pass things in, then take them out again, literally the agent couldn't and wouldn't try to break through 2 layers of security in order to get your banking details or whatever.
It can still get infected and be used as an attack vector by some hidden prompt or some other equally advanced state of the art vuln like "disregard all previous instructions"
https://oneuptime.com/blog/post/2026-03-02-ufw-docker-fix-by...