Agents are fundamentally insecure, there’s no getting around it. You can put OpenClaw in a box but for it to do anything useful it still needs some access to the outside world, and any untrusted tokens that go into its context are a threat.
Claude’s auto mode classifier is probably the best ‘firewall’ out there right now, but it’s a non deterministic layer with a failure rate of 17%.
I run a home-grown 'Agent' by just making a local user on my linux box. I treat it like an untrusted local user, I only give it scoped API keys, and manage permissions just like any other thing. I have a NixOS machine and I have the Agent setup to just use home-manager to manage itself and its timers and deps and stuff inside its own config.
It would be insane to run a full fledged Agent from your own accounts, with the same access as yourself. At the same time running it fully scoped inside a container/VM seemed a little bit too heavy handed to me and the Agent-as-user seems like a better fit for me right now. (I did run my coding agents inside a microVM for a while but ran into a few too many annoyances)
What were the annoyances you faced?
arent the recent RCE vulnerabilities the agent as user equally vulnerable to, just way more obscured. id be curious if someone has tried a prompt injection form of attack.
its kinda amusing to think if something like mythos actually is a competent malware expert, then users of it could easily be vupnerable to prompt injection attacks.
Better to run a simple full virtual machine. It's easy to spin one up on any modern linux distro (okay, not as easy it is in Qubes-- only three mouse clicks, but still pretty easy).
There are many advantages of running it in a VM: really clean and strong sandboxing and it's easy to put that VM behind its own VPN / firewall external to the VM to reduce the escape risk.). It's also handy if you run a different distro than the agent ecosystem, since you can just run whatever OS works best for the agent.
[dead]
I know it's probably against the guidelines to comment on it, but any chance you could ask whatever agent is responsible to remove the scroll highjacking? It makes it incredibly tedious to read this article.
I am under the impression that the end game will look a lot like Apple's closed ecosystem. They are reinventing filesystem permissions, networking security, but most importantly trust on extensions provenance.
Probably a good thing but it will remove a lot of the fun.
What is happening in the first screenshot under "Command approvals and prompt fatigue"?
Why is "Allow Once" completely red, "Always allow" is black and "Deny" is muted red? Isn't the order of safety (descending) "Deny", "Allow Once" and "Always Allow"?
I think it's something to do with macos dark mode and accent colors.. So allow once is highlighted because it's the default option if you press enter. The next button is dark because it's themed and people (errr LLMs) who wrote the code didn't consider that a button should be distinct from the background theme of the window. And finally the other one's text is red because it's a dangerous action.
Isn't a lot of this what containerization was supposed to solve? Why are they reimplementing file system isolation from scratch when jails and chroots exist? Why do they have to reason about arbitrary HTTP requests when firewalls and content filtering exist?
Because they don't know what they are doing.
In any case, a proxy makes sense, just not for the reasons they give.
And it sounds like the proxy can be easily circumvented by the agent, since it only applies within the Node process and the agent can execute arbitrary external commands.
(The filesystem wrapper API sounds even more pointless. The risk it protects against seems insignificant compared to the other risks associated with their system.)
The proxy can be circumvented if the agent can execute arbitrary commands. This is where you’d start if you were planning to enable a world in which it’s more deliberately scoped.
People are running these as a program under their admin permissions, right? That seems to be the root problem to me. Start with having it run under its own user and you could use firewalls and permissions and keep it siloed to some Home directory or etc that you just copy files to?
The people building this aren't good at engineering reliable systems, as evidenced by the incredibly wasteful core premise of what they're doing.
The answer is that they probably aren't aware of all these things.
Namespaces and cgroups allow for resource accounting and limited isolation between trusted processes. It is only through hard work and luck that they have been usable in the k8s/docker world.
To be 100% clear, namespaces are not a security feature in themselves, but can be used to run processes with reduced privileges and improved isolation, but not for untrusted code.
A few reasons.
1) Kernel features explicitly need to support namespaces, and only the portions that support namespaces have increased isolation, any syscall, socket family, etc… can provide an attack vector for the global kernel.
2) The methods to further constrain processes like LSMs, SecComp, eBPF system calling typically are not implemented by common container images and are difficult for users to develop and deploy.
3) User namespaces have actually increased exposure to user data, if protecting the system itself because of the proliferation of capabilities(7)[0]. Capabilities were designed as a vertical slice of superior(root) user functionality, and the contract is much different than people expect[1][2] We will have to see where things go, but as far as untrusted code, no containers/namespaces/etc… are not sufficient at all. There are just too many holes in the shared kernel and several socket() based backends that are used through netlink etc… Here you can see just how insane the number of default capabilities are granted to every user right now.
$ grep ^CapBnd /proc/$$/status
CapBnd: 000001ffffffffff
$ capsh --decode=000001ffffffffff
0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore
So then how does bubblewrap/firejail do it through namespaces?
Bubblewrap tends to be better at defaults than docker/rancher/podman, where the users rarely use `USER` and/or drop elevated privileges, it still has the same limitations.
It is just the reality that namespace/seccomp/ebpf/cgroups are privilege dropping and are not jails.
But it is better with common command line options like:
$ bwrap --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib /lib --ro-bind /lib64 /lib64 --ro-bind /sbin /sbin --ro-bind /etc /etc --proc /proc --dev /dev --tmpfs /tmp /usr/bin/bash
$ grep ^Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000000000000000
CapAmb: 0000000000000000
$ grep ^NoNew /proc/$$/status
NoNewPrivs: 1
But at least they tend to default to running without elevated privileges.
Note from the bwrap repo[0]
Whatever program constructs the command-line arguments for bubblewrap (often a larger framework like Flatpak, libgnome-desktop, sandwine or an ad-hoc script) is responsible for defining its own security model, and choosing appropriate bubblewrap command-line arguments to implement that security model.
Warning
Bubblewrap is a tool which provides sandboxing technologies like namespaces and seccomp filter. It does not by default provide a full sandbox that isolates weakpoints of a used technology. Running untrusted code is never safe, sandboxing cannot change this.
grep net-pf /lib/modules/`uname -r`/modules.alias
/etc/modprobe.d/blacklist-rare-network.conf
Note that the LSM like apparmor may add constraints on aa systems look at[2]
The bwrap team is better at working the with LSM teams, while OCI actively refuses to give guidance and has a dangerous profile [3]
Once again namespaces/cgroups/seccomp/avoiding elevated privlages/etc... are all important for running with minimal privileges, but yes 'sandboxes' and 'containers' provide much less isolation than most people realize.
[0] https://github.com/containers/bubblewrap#limitations [1] https://wiki.archlinux.org/title/Bubblewrap [2] https://gitlab.com/apparmor/apparmor/-/blob/master/profiles/... [3] https://gitlab.com/apparmor/apparmor/-/blob/master/profiles/...
No, containerization has nothing to do with secure separation and never has.
[dead]
[dead]