7 ms·

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 r

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.

lucaspiller 4mo ago
My agent has access to my email, my messages, my work, my finances, my life. But thank god it doesn't have access to root on my machine.
- mmh0000 4mo ago
  As always. XKCD: https://xkcd.com/1200/ https://xkcd.com/1200/
gopher_space 4mo ago
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.
- overfeed 4mo ago
  I'm more worried about my `~/.aws` and `~/.ssh` folders. People who use IDE-based AI tooling with IDEs that support dev-containers have no excuse for not leveraging dev containers, both for preventing agents losing your data and defending against secrets-harvesting supply-chain attacks
  - l23k4 4mo ago
    Using containers as a security boundary is inexcusable.
    - koolala 4mo ago
      It is excusable if all you care about is blocking sudo access while letting the ai use a pseudo sudo.
    - rafterydj 4mo ago
      Could you elaborate on this?
      - l23k4 4mo ago
        The cost-benefit ratio of using VMs over containers is very high. You trade negligible overhead for an actual security boundary. Containers don't provide good isolation and tend to be trivial to break out of.
    - overfeed 4mo ago
      That entirely depends on one's threat-model. Also, containerization is 100x better than rawdogging.
      - l23k4 4mo ago
        > That entirely depends on one's threat-model 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.
- sersi 4mo ago
  It's why all of my agent run in a vm. I refuse to have it run on my own machine. Claude code once managed to render the vm unbootable, I was back in action 5 minutes later after regenerating the vm
  - mancerayder 4mo ago
    What were you trying to tell it to do? 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.
    - sersi 4mo ago
      oh I just told it it could install any dependencies it needed. To be fair, the VM runs arch linux and well arch does come with foot guns.
shevy-java 4mo ago
Ok but in this case the problem wasn't the AI agent - the AI agent merely took advantage of this prior problem in the first place. For instance, if docker group were not superuser-like, that issue could not have happened. > 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.
latexr 4mo ago
> Nothing short of sandboxing everything or just never using AI agents or proprietary software will prevent this. 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.
dark-star 4mo ago
If malicious AI has replaced the sudo binary, then it can already run arbitrary code as root. No need to "collect your password" then
- ikurei 4mo ago
  It could just alias sudo on your ~/.bashrc. No need to replace the actual file on /usr/bin/sudo or wherever you have it. I would only need to be able to run arbitrary code as you.
smegger001 4mo ago
Sigh. What ever happened to the principle of least privilege and why arent we applying it to AI agents. They ought to be locked in a box and not capable to act outside designated task.

lucaspiller 4mo ago

My agent has access to my email, my messages, my work, my finances, my life. But thank god it doesn't have access to root on my machine.

mmh0000 4mo ago
As always. XKCD: https://xkcd.com/1200/ https://xkcd.com/1200/

gopher_space 4mo ago

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.

overfeed 4mo ago
I'm more worried about my `~/.aws` and `~/.ssh` folders. People who use IDE-based AI tooling with IDEs that support dev-containers have no excuse for not leveraging dev containers, both for preventing agents losing your data and defending against secrets-harvesting supply-chain attacks
- l23k4 4mo ago
  Using containers as a security boundary is inexcusable.
  - koolala 4mo ago
    It is excusable if all you care about is blocking sudo access while letting the ai use a pseudo sudo.
  - rafterydj 4mo ago
    Could you elaborate on this?
    - l23k4 4mo ago
      The cost-benefit ratio of using VMs over containers is very high. You trade negligible overhead for an actual security boundary. Containers don't provide good isolation and tend to be trivial to break out of.
  - overfeed 4mo ago
    That entirely depends on one's threat-model. Also, containerization is 100x better than rawdogging.
    - l23k4 4mo ago
      > That entirely depends on one's threat-model 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.
sersi 4mo ago
It's why all of my agent run in a vm. I refuse to have it run on my own machine. Claude code once managed to render the vm unbootable, I was back in action 5 minutes later after regenerating the vm
- mancerayder 4mo ago
  What were you trying to tell it to do? 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.
  - sersi 4mo ago
    oh I just told it it could install any dependencies it needed. To be fair, the VM runs arch linux and well arch does come with foot guns.

shevy-java 4mo ago

Ok but in this case the problem wasn't the AI agent - the AI agent merely took advantage of this prior problem in the first place. For instance, if docker group were not superuser-like, that issue could not have happened. > 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.

latexr 4mo ago

> Nothing short of sandboxing everything or just never using AI agents or proprietary software will prevent this. 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.

dark-star 4mo ago

If malicious AI has replaced the sudo binary, then it can already run arbitrary code as root. No need to "collect your password" then

ikurei 4mo ago
It could just alias sudo on your ~/.bashrc. No need to replace the actual file on /usr/bin/sudo or wherever you have it. I would only need to be able to run arbitrary code as you.

smegger001 4mo ago

Sigh. What ever happened to the principle of least privilege and why arent we applying it to AI agents. They ought to be locked in a box and not capable to act outside designated task.