3 ms·
> You check out a file with git, then edit it with vim, and build it with gcc, which pulls in headers generated with a python script, itself having been configu
by comex 7y ago
> You check out a file with git, then edit it with vim, and build it with gcc, which pulls in headers generated with a python script, itself having been configured with, I dunno, cmake gadgetry. Where do you draw the boundaries here?
Have you heard of Plash?
http://www.cs.jhu.edu/~seaborn/plash/html/ http://www.cs.jhu.edu/~seaborn/plash/html/
While the software itself is outdated, and the design is fundamentally limited by the goal of compatibility with existing Unix programs, I think it's a good proof-of-concept of how you could design a sandboxed command line, especially if you were building everything from scratch.
Basically, any filename argument you pass to a command is no longer just a string; it becomes a capability granting that command access to that file.
So:
- Check out with git: `git clone https://url https://url foo` includes `foo`, so you're giving it permission to create a directory named `foo`. Other git commands don't take the repo root as an argument. If you're redesigning the world, perhaps they should. Alternately, git could have a custom sandbox that identifies the directory containing .git and grants access to the whole thing.
Note: In Plash you have to stick in `=>` to grant read-write access, but I'll ignore syntax details since I'm thinking more in terms of broad strokes of a hypothetical design.
- Edit with Vim: `vim foo.c` gives permission to `foo.c`. (Vim also supports opening new files within the editor; in theory that could be redirected to some sort of powerbox, though it's harder than with GUIs.)
- Configure with cmake: `cmake .` would grant permission to read/write the current directory.
- Run make: You'd want syntax like `make .` rather than implying the current directory. (Again, Plash has a solution for this but I don't care about the specifics.)
- Generate headers with a Python script: make would invoke the script, passing it the input/output paths as capabilities.
- Build with GCC: One of the Plash examples is `gcc -c foo.c => -o foo.o`.
- gioele 7y ago> - Edit with Vim: `vim foo.c` gives permission to `foo.c`. (Vim also supports opening new files within the editor; in theory that could be redirected to some sort of powerbox, though it's harder than with GUIs.) Will Vim be allowed to read `~/.vimrc`? If not, how should I configure Vim system-wide? (If the answer is "with a daemon", then: is Vim allowed to connect to the daemon and read its configuration?) If yes, why? (If the answer is "because you configured the system so", then: how is this different from SELinux?) Just kidding. :) The thing is that access to shared state is hard. Any access is a potential security threat. Finding a balance between functionality and security is one of those areas that I fear are in the NP-hard-equivalent area of system design.