The "permissions as access/visibility" is unfortunately not holding up in practice. As nice as a simplification like this would be: No one wants to configure up front what permissions are needed. Users will run into annoyances and then just overcommit resource access the same way they choose to run yolo mode. Limiting access for security is a great part of a capability based system but a system that will be used in the way intended needs the following properties, which are mostly missing from the tools we have (apparmor, seccomp, oss VMs, seatbelt, docker, bubblewrap etc.)
- pause execution for a policy engine or user input
- variable scope permissions independent of what was requested. eg user needs to allow just this request to /test/myfile.txt or grant /test/* in that moment
- add (ideally also remove) capabilities based on dynamic user input or engine decisions without up front configuration
- not need application support, if apps need to support it the moment the harness uses an external tool the model breaks
deno, workerd and maybe a vm/docker solution with an webdav proxy mount and web-proxy are the only environments i am aware of where systems like this could be build at all, even there, with limitations. (Not writing this to sound absolute but to learn about other options I am missing.)
do you know of a mitm proxy that "just works"? meaning, is able to spoof/intercept/modify running processes well enough that most stuff would run without manual modification?
There are tons that are all too simple or too complex or made for mesh networking in k8, or too slow and made for debugging. My go-to solution is to make ad-hoc proxies with workerd that work just the way i need and compile to a "binary". It used to be annoying to write capnp by hand but now you just point an agent at worker.capnp and tell it what you need. The output is concise enough to be nice for proper reviewing and as extendable starting point, so neither vibe coding nor much manual coding needed.
> The agent inside the container runs with bypassPermissions — it can use Bash, write files, do whatever it wants. But "whatever it wants" is constrained by what the OS lets it see. No application-level permission checks needed.
While containers can be useful for reducing privileges, that assumption isn’t safe, remember that the only thing namespaces away is that which supports namespaces and that by themselves, namespaces are not security features.
A super critical part I didn’t see or missed is the importance of changing UID, the last line of [0] will show one reason.
Remember that the container users has elevated privileges unless you the user explicitly drop this privileges.
I applaud the effort at hardening, but containers have mostly been successful because the most popular apps like nginx operate under a traditional cohosting system and take responsibility for privilege dropping.
There are tons of kernel calls, ldpreload tricks etc… that are well known and easily to find with exploration.
Even dropping elevated privileges and setting no new priv, still isn’t a jail.
Without using separate UIDs don’t expect any real separation at all.
yeah me too. It's a shame because I'm sure the content of it is very precise when it comes to the technical data. It is just that, if this post has been made to be consumed by other humans, it would be better written from the experience and intepretation of another human being. It is a blog post, not a science investigation or law document
It's been about a month since I last looked at nanoclaw, but comparing with openclaw seems silly. It's like comparing pi.dev with Claude Code. nanoclaw has a lot fewer capabilities than openclaw, with the expectation that you'll essentially build your own features on top of it (and likely end up as buggy as openclaw).
I really like solving the prompt injection credential exfiltration risk by never giving the container real keys in the first place. I wonder how prolific that pattern will become.
13 comments
- pause execution for a policy engine or user input
- variable scope permissions independent of what was requested. eg user needs to allow just this request to /test/myfile.txt or grant /test/* in that moment
- add (ideally also remove) capabilities based on dynamic user input or engine decisions without up front configuration
- not need application support, if apps need to support it the moment the harness uses an external tool the model breaks
deno, workerd and maybe a vm/docker solution with an webdav proxy mount and web-proxy are the only environments i am aware of where systems like this could be build at all, even there, with limitations. (Not writing this to sound absolute but to learn about other options I am missing.)
> web proxy
do you know of a mitm proxy that "just works"? meaning, is able to spoof/intercept/modify running processes well enough that most stuff would run without manual modification?
> The agent inside the container runs with bypassPermissions — it can use Bash, write files, do whatever it wants. But "whatever it wants" is constrained by what the OS lets it see. No application-level permission checks needed.
While containers can be useful for reducing privileges, that assumption isn’t safe, remember that the only thing namespaces away is that which supports namespaces and that by themselves, namespaces are not security features.
A super critical part I didn’t see or missed is the importance of changing UID, the last line of [0] will show one reason.
Remember that the container users has elevated privileges unless you the user explicitly drop this privileges.
I applaud the effort at hardening, but containers have mostly been successful because the most popular apps like nginx operate under a traditional cohosting system and take responsibility for privilege dropping.
There are tons of kernel calls, ldpreload tricks etc… that are well known and easily to find with exploration.
Even dropping elevated privileges and setting no new priv, still isn’t a jail.
Without using separate UIDs don’t expect any real separation at all.
[0] https://www.kernel.org/doc/html/latest/admin-guide/namespace...
"70% of startups fail due to premature scaling"
.. which is a link to another blog post somewhere else that says nothing even slightly related.
- Antoine de Saint-Exupéry
jk