Hacker News Reader

I see what you're saying, but I think we can do better.

I would really like some simple way to limit what build scripts can do. For example, they shouldn't be able to read and write arbitrary files in my home directory, even though they should be able to read /usr/lib and the like. They shouldn't be able to contact the Internet (or even the LAN) without explicit permission. They shouldn't be able to do anything with my display unless I permit it.

Is there some command available for Linux that lets me set up a quick sandbox so I can detect and stop trojans in build scripts? Virtual machines, chroots, containers, and Docker are all good but they don't solve this problem. SELinux has the potential to solve this but it's extremely complex. Instead of "./configure && make", I want to type something like "sandbox ./configure && sandbox make"; sandboxed build scripts should work the same as if they're outside the sandbox.

Docker could do that for you. Windows also got/is getting a lightweight sandbox though I don't recall how to invoke it.

Docker is not intended to be a sandbox in any way.

https://news.ycombinator.com/item?id=9087421

If you're running docker with the "userns-remap" option, it is a form of sandbox insofar as any userspace isolation provided by Linux is a sandbox; you would probably need a root privilege exploit to break out of it. If there are root privelege exploits in Linux, they should obviously be fixed.

Of course, we should be aware that exploits are quite likely to exist, since much of Linux was designed without a notion of namespaces.

For me, the main issue with docker in terms of security is that it's not clear what security you're giving up when running containers (eg, various projects expect you to do `docker run -v /var/run/docker.sock:/var/run/docker.sock ...`, and things like `docker-compose` essentially specify arbitrary invocations of containers). When ways of escaping are discovered, they get fixed, since those escaping mechanisms are not really considered part of the execution model for containers.

The discussion is a bit dated, docker now supports user namespaces such that apps can run as root inside a container, but are not root outside of the container.

I'm running podman(docker replacement) on fedora for many things. It can run as a user without root permissions, does not need a daemon and containers get their own SELinux policy by the fedora devs. Far from perfect, definitely better than nothing.

What you describe is called Mandatory Access Control, which is in contrast and supplements standard UNIX Discretionary Access Control (user/file permissions). It is implemented on Linux with AppArmor in addition to SELinux.

I would guess the biggest hurdle in using such systems is the complexity and expertise required in drafting the specific rules that should apply in your threat model.

If you craft rules for your cmdline tool you will run into problems pretty soon despite the complexity. Better is using a wrapper that is confined. See e.g. SELinux' sandbox(8) which is more or less a "multiwrapper" in that it sets the context explicitly and not implicitly by being confined.

The nix package manager comes close to what you’re describing. Each package build is sandboxed so that it can only read files from explicitly defined dependencies. It also confines writes to a subdirectory in /nix/store, assigned to each package.

Where I work, we by now have all build steps of server-side code occurring in containers, and all local dependencies for that are `docker`, `git`, and `make`.

Though docker does not completely isolate the build process, it definitely limits writable local directories to those explicitly mounted into a container.

An extra bonus is that docker also installs on Windows and on MacOS and is controlled seamlessly, so our developers are free to choose whatever OS is needed for native development.

There is SELinux' `sandbox(8)`. It is explicitly designed for that purpose.

Qubes might fit this description better, but I haven't had to use it really

> 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/

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 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`.

> - 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.

Your IDE comment made me think of this. IDEs store each project completely self contained in its own directory. How about allowing some directories to be marked as development dirs. A blacklist of commands when run inside that directory will be prohibited from accessing anything outside that directory, except for read-only access to /usr etc. and RW access to whitelisted dirs.

For example: I mark ~/school/operating-systems as a development directory. I place git, vim, wget, curl, and make on the blacklist (potentially globally-configured). Additionally I whitelist ~/.config/git for git and ~/.vim for vim. This allows core commands that we consider 'safe' like cd, mv to be run without restrictions - presumably they are only being used manually or from sandboxes tools like Make. But when I execute git from anywhere inside ~/school/operating-systems, it will only be able to R/W inside that directory and within the ~/.config/git directories. Meanwhile read access to system folders lets Make etc. work properly.

With a single global configuration + directory-specific overrides, it remains pretty straightforward and doesn't require a huge time investment like AppArmor/SeLinux do. Meanwhile all non-dev work remains unaffected. If you need to download and build a random program, just mark it as a dev directory and you're pretty safe. It's not perfect, but better than nothing

Is this problem not solved by virtual environments or chrooting ? Potentially a simple wrapper script could be created around chroot that only installs the programs you need.

Chrooting loses global configuration files and libraries and tools that you have installed. This has a similar effect, is not as strong, but is simpler.

Ah yes, good point. Although I am sure you could sort it all out in some kind of wrapper script. Although it's not that simple then.

Well, you can do it right now with firejail. Start with the default config, it prevents access to many sensitive files; then either add more sensitive locations to blacklist, or blacklist your whole home directory and whitelist whatever is necessary.

I don't recall the exact configuration format, but it's something really simple, like

    whitelist ~/src/*

> 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?

None of this should not require access to things like my web browser, my ~/.config directory, some directory like ~/build/go containing an unrelated project.

> They're called "IDE's"

IDEs don't exist for security reasons, but I think you can at least use the existence of these things as evidence that there is a sensible way of scoping development activities. I imagine it wouldn't be a major hindrance if IDEs did provide this sandbox functionality, where you could still launch a shell within the IDE, and that shell would be in a mount/pid namespace controlled by the IDE.

Personally, I want something that applies not just to development, but general computer use. If you go back 15 years, it was probably fairly typical for someone to expect to download an run an "EXE" file. Now the expectation is that a website or phone app is used instead, which has fewer security implications.

Surely there must be some path for moving to something more secure when it comes to commandline usage.

> None of this should not require access to things like my web browser, my ~/.config directory

It does! I want to configure git and vim globally, I want to start a development server and use my browser to access it. I want to netcat a file because IT policies restrict ssh...

Unix has this built-in tool called "su" that allows you to "sandbox" different parts of the filesystem. Pretty handy.

"su - project1"

> I mean, you can draw a big circle around all your development activities. Products have been invented that do that. They're called "IDE's", and are sort of the metaphorical opposite of the command line tools we're discussing, and not really a solution to the people choosing to use this environment.

Maybe? I don't really think it's an opposite thing anymore. Most of my projects are written/browsed/debugged in an IDE but not built/configured/etc. in the IDE, and the testing, git, docker, code review, etc. work just happen in a console instance or web browser next to the IDE.