Comment by throwaway2027
15 hours ago
All of which is useless when it just starts using big blocks of python instead. You need filesystem sandboxing for the python interpreter too.
15 hours ago
All of which is useless when it just starts using big blocks of python instead. You need filesystem sandboxing for the python interpreter too.
If you disallow it from just writing Python scripts to bypass its defined environment at its core system training why would this matter? I would lockdown its path anything that tries to call Python should require the end-user to approve and see the raw script before they do.
It will then write script in some other language, as a workaround.
What we need is a capabilities based security system. It could write all the python, asm, whatever it wants and it wouldn't matter at all if it was never given a reference to use something it shouldn't.
There exist restricted Shells. But honestly, I don't feel capable of assessing all attack vectors and security measures in sufficient detail. For example, do the rbash restrictions also apply when Python is called with it? Or can the agent somehow bypass rbash to call Python?
https://en.wikipedia.org/wiki/Restricted_shell
Isn't this already possible? Give it its own user account with write access to the project directory and either read access or no access outside it.
Unix permissions is not a capability system though. Capabilities are more like "here is a file descriptor pointing to a directory, you are not capable of referring to anything outside it". So closer to chroot, except you can have several such directory references at the same time.
You can always narrow down a capability (get a new capability pointing to a subdirectory or file, or remove the writing capability so it is read only) but never make it more broad.
In a system designed for this it will be used for everything, not just file system. You might have capabilities related to network connections, or IPC to other processes, etc. The latter is especially attractive in microkernel based OSes. (Speaking of which, Redox OS seems to be experimenting with this, just saw an article today about that.)
See also https://en.wikipedia.org/wiki/Capability-based_security
I have been putting my agents on their own, restricted OS-level user accounts for a while. It works really well for everything I do.
Admittedly, there’s a little more friction and agent confusion sometimes with this setup, but it’s worth the benefit of having zero worries about permissions and security.
1 reply →
Docker is enough in practice no?
[dead]
[dead]