Hacker News Reader

Comment by hathawsh | 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.

View on HN

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.

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

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.

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.

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.

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.

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

Reply on news.ycombinator.com