Allowlisting some Bash commands is often the same as allowlisting all

Allowlisting some Bash commands is often the same as allowlisting all(joinformal.com)

37 points by drewgregory 156 days ago | 25 comments

sadnboxx 156 days ago |

Allowing a "command" (executable, I believe) that isn't a read-only absolute path is a fool's errand. I will modify PATH and run my own implementation of it.

eqvinox 156 days ago |

everything is a container these days, and yet somehow collective-we don't manage to have AI agents run in a container layer on top of our current work, so we can later commit or rollback?

iberator 155 days ago | |

What do you mean?! Where? I would claim otherwise: 99% of software is not in the containers. Like 100% windows or debian software

slipheen 151 days ago | | |

I don't know much about how windows software is packaged, but I find that a solid majority of desktop software I use is in flatpack and server software in OCI images

Neywiny 155 days ago | |

I feel like if I ever used an agentic AI that's how I'd need it to be done. Too many cases of AIs getting access to files that it shouldn't. But then then, how do I allow it to look things up online without sending all my code to some scammer that prompt injected on a tutorial? I don't think I'll ever trust it with anything proprietary or otherwise less than publicly available.

zufallsheld 156 days ago |

Same thing for allowing specific sudo-commands. Many tools (like vim or the tools mentioned in the article) would have the same problem when allowing them to be run with root privileges.

denysvitali 156 days ago | |

=> https://gtfobins.org/

Terr_ 151 days ago | | |

Now I feel a bit more justified for over-engineering my automatic restic backup to not run as root, but to instead use "capabilities" to read files it doesn't own.

Namely, CAP_DAC_READ_SEARCH [0] and related systemd settings. The only problem is that it inhibits using a convenience/wrapper script.

[0] https://www.man7.org/linux/man-pages/man7/capabilities.7.htm...

illusive4080 155 days ago | |

Some at work want to let me run sudo vim only to edit my hosts file. This is silly for a variety of reasons, one of them being that vim can allow the user to exec arbitrary commands. If you give me root for vim, just save me the trouble and let me have unrestricted root so I can do my job.

bauruine 155 days ago | | |

I had the same few years ago. When I pointed out that I can get full root with most of the whitelisted commands they answered "We know. It's not about security but to prevent lusers from accidentally rm -rf /* the server. Feel free to spawn a root shell. You obviously know what you do"

CableNinja 155 days ago | | |

I deal with some regulated things and some users who usually wouldnt be allowed to see/work on a thing are granted special access to do so, with extreme limitations. Recently i was approached asking if we could strip down the users desktops to no gui, no sudo, for use as a jumpbox. I explained why users need sudo to do what they need, and was asked about limiting sudo.

Its really tough to tell someone who is all about security (not linux security but regulatory security and such) that basically granting any bit of sudo access can lead to full access.

There is a way that this can be handled, but its honestly sort of an afterthought functionality. facls. You can delegate multiple owners/groups and permissions for things, and it can work well, but you have to deal with facls on multiple fronts, setting them for basically the entire system. facls are great, in theory, but they feel like such an afterthought that they are often ignored.

totetsu 151 days ago |

I remember when I was starting out, someone on my team showed me, that in the case where we were allowed to run vi and root on a machine there was noting stopping one from just starting a child shell from within vi with root privileges.

AllegedAlec 151 days ago |

Not entirely related to the content but man 'allowlisting' reads so badly. We should just out of ease of reading return to whitelisting.

slipheen 151 days ago | |

I'm trying not to get nerdsniped, but in the realm of subjective pragmatics, I personally find `allowlisting` to be drastically more clear.

AllegedAlec 151 days ago | | |

My concern isn't really clarity of intention, but that 'allowlisting' just doesn't flow as well when reading as whitelisting does.

with 151 days ago |

True, you can do almost anything if find is allowlisted.

find / -exec sh -c 'whatever u wanna do' \;

pimlottc 156 days ago |

I know they’re just being through but the “go test” part is a bit “Pray, Mr Babbage”… Test code is just code. I know of no language where tests are sandboxed in any meaningful way.

bloppe 155 days ago | |

They're sandboxed if you use bazel. Not as much as the nix people would like, but bazel tests get read-only access to the host filesystem except /tmp

pimlottc 155 days ago | | |

Right, I should have said there are conventions and libraries you can use to limit the scope of tests but that requires intention and diligence. But fundamentally , “go tests” could run anything a normal go program can.

hbogert 155 days ago |

> I really thought `eval` would not be abused on non validated input

    - your colleague, or you 1 year before.

bandrami 151 days ago |

I'm sorry but the idea of giving an AI agent a non-restricted shell is insane. If you don't want it to perform certain commands those commands should not be in its environment at all.

teddyh 156 days ago |

“…with Claude Code”

extraduder_ire 156 days ago | |

The same caveats would apply to most kinds of restricted shell environments.

adastra22 156 days ago | |

Are there any agent permission systems that do this correctly?