I have this idea. It’s taken from the Android world. In Android, apps all get their own user, and can only access their own filesystem. They are then added to groups like Sound or Files or whatever to gain access to other things. This is simplifying but gave me an idea.
So my idea is two parts:
We add more groups to our Unix and Unix-like codebases. Piecemeal access to different folders like a fs-docs group for access to /home/<whoever>/Documents
Each app, when installed, gets a user and a folder (maybe /opt/<pkgname> or /apps/<pkgname> and a group called app-<pkgname>). It requests during install (or maybe runtime via a permissions management application) access to specific groups for its user. Launching an app then becomes sudo -u app-<name> /opt/<pkgname>/<binname>.
You login as a user with access to limited permissions and then run the application. Thus you run it sandboxed but without special software like Flatpak or AppImage - just standard Unix groups.
Claude code I believe has its own sandboxing system, but with this system it would be the system itself restricting claude, not the claude code app, truly limiting accidental outreach.
I built a demo package manager using this concept a while back called ‘bokspm,’ though I kept it private (and now, my current job will not let me open source it)
No my proposed solution uses the “everything-is-a-file” aspect of Unix-like systems with the built-in permissions systems around files. You don’t need cgroups at all for what I’m suggesting
Well, these are some kind of lightweight container, no? But without isolating network, or /etc, /proc, /usr, /var or dbus.
I do agree that linux needs a notion of an “app” (isolated, with access only to its config and files you give it, and a small, well-designed set of APIs for interacting with the system). For coding agents, I think a better answer are development containers, because that would be needed to prevent npm/cargo/python build scripts from causing harm anyway.
I’m not suggesting containers but rather running binaries natively, just as separate users. No cgroups or overhead. Just normal binary access, just you won’t have access to all files (and since everything is a file, “all files” includes hardware as well)
I have this idea. It’s taken from the Android world. In Android, apps all get their own user, and can only access their own filesystem. They are then added to groups like Sound or Files or whatever to gain access to other things. This is simplifying but gave me an idea.
So my idea is two parts:
fs-docsgroup for access to/home/<whoever>/Documents/opt/<pkgname>or/apps/<pkgname>and a group calledapp-<pkgname>). It requests during install (or maybe runtime via a permissions management application) access to specific groups for its user. Launching an app then becomessudo -u app-<name> /opt/<pkgname>/<binname>.You login as a user with access to limited permissions and then run the application. Thus you run it sandboxed but without special software like Flatpak or AppImage - just standard Unix groups.
Claude code I believe has its own sandboxing system, but with this system it would be the system itself restricting claude, not the claude code app, truly limiting accidental outreach.
I built a demo package manager using this concept a while back called ‘bokspm,’ though I kept it private (and now, my current job will not let me open source it)
Using cgroups for isolating processes into their own individual network, filesystem, user, etc. namespaces using a shared kernel?
You mean containers?
No my proposed solution uses the “everything-is-a-file” aspect of Unix-like systems with the built-in permissions systems around files. You don’t need cgroups at all for what I’m suggesting
You wouldn’t even need sudo. Just suid the binary.
Flatpak
Overhead
And for a number of reasons this isn’t like flatpak at all.
Well, these are some kind of lightweight container, no? But without isolating network, or /etc, /proc, /usr, /var or dbus.
I do agree that linux needs a notion of an “app” (isolated, with access only to its config and files you give it, and a small, well-designed set of APIs for interacting with the system). For coding agents, I think a better answer are development containers, because that would be needed to prevent npm/cargo/python build scripts from causing harm anyway.
I’m not suggesting containers but rather running binaries natively, just as separate users. No cgroups or overhead. Just normal binary access, just you won’t have access to all files (and since everything is a file, “all files” includes hardware as well)
Does AppArmor kind of do that? I recall recently struggling like fuck to give a torrent daemon app access to some script file I wanted it to run.
https://jai.scs.stanford.edu/