231–240 of 330 posts
Earlier quoted context omitted.
If this happens in the US, a shooting of the messenger will likely occur.
As you can see from people blaming Codex instead of docker here, shooting of the messenger is very much happening.
Earlier quoted context omitted.
This feels like using sudo is just inherently unsafe.
This but unironically. There's no way to ensure that nobody overwrote your .profile or .bashrc with a backdoored sudo that steals your password, or runs your command and then runs an evil command afterwards.
`/usr/bin/sudo`?
Earlier quoted context omitted.
User namespaces significantly rise the risk of exploits and many setups disable them. One may argue that Docker should have used them when they were available, but that would break too many useful setups involving privileged containers.
Ah of course, we should not use userns because it might be vulnerable to some yet to be discovered vulnerability. The better alternative is to give full root access so we won't have surprises.
Earlier quoted context omitted.
wait so just being lazy and using sudo on Docker commands instead of figuring things out actually means I'm being safer? awesome.
No, because a malicious AI agent could just replace the sudo binary in your path with one that collects your password and uses it to execute arbitrary code as root. Nothing short of sandboxing everything or just never using AI agents or proprietary software will prevent this.
> 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.
Earlier quoted context omitted.
My understanding is that docker will expose the ports to the host machine's network interfaces, which is a crucial difference. For my home server running docker that means exposed to the LAN, but not the WAN unless I add in a port forwarding rule on my router. Similarly in an enterprise environment you would be exposing the port on whatever VLAN the host is connected to, which hopefully doesn't have directly transit…
If you ever suddenly get IPv6, it may become globally reputable without you realizing.
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.
Earlier quoted context omitted.
No, because a malicious AI agent could just replace the sudo binary in your path with one that collects your password and uses it to execute arbitrary code as root. Nothing short of sandboxing everything or just never using AI agents or proprietary software will prevent this.
Once I noticed that models will treat lack of superuser access as an obstacle I moved all of the agent crap to its own machine. Watching some mid-tier offering chain together tools like its a gorilla escaping the zoo and I'm just not going to deal with that situation.
The concept of sudo has always been strange to me. I find it as an illusion of security and a hassle but people seem so focused on must-use it that they don't typically see it in that way. For instance, before wanting to evaluate sudo, why is not the underlying premise challenged that using a computer as superuser is a problem? Whenever I ask that question, people try to bring arguments as to why using the superuser…
Earlier quoted context omitted.
This but unironically. There's no way to ensure that nobody overwrote your .profile or .bashrc with a backdoored sudo that steals your password, or runs your command and then runs an evil command afterwards.
`which sudo`? `/usr/bin/sudo`?