Hacker News Reader

> any application is supposedly running in its own sandbox,

But that fails for developers (which is more or less synonymous with "CLI users"). Development is all about data and fine grained tools, not apps.

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?

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.

Alternatively, you can view the whole development system as a sandbox. Do your work in a separate VM or docker instance, for example. Some people actually do that (in particular folks with windows desktops who need linux tooling will recognize this), and while it's not generally considered a security technique, it certainly could be.

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

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

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

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?

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.

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

"su - project1"

This is what AppArmor and SELinux are used for. AppArmor has the ability to apply a profile whenever a particular binary is run, and so you can confine the process. SELinux has labels and all that jazz so you could probably configure it in a similar manner (though I think it doesn't support restricting all callers of a binary).

To a lesser degree, seccomp is similar but you don't have an easy way of applying a profile to a binary (instead the binary would need to self-apply the profile or you'd need to come up with a separate way of running programs so that a profile would be auto-applied).

The problem is that users want to be able to edit any file on the filesystem with their text editor -- if you don't allow vim to edit files in /etc/ then admins won't be able to do their job (though, please use "sudo -e" instead of "sudo vi").

though I think [selinux] doesn't support restricting all callers of a binary

It can, in two ways: the current context (say, user_dev_t) needs execute permissions on the declared type of the executable (say, git_exec_t), and additionally, you can declare a type transition to be performed per calling context.

To keep with the git example (I admit it's a bit contrived), you could label your .git directory as git_repo_t and deny access for both user_t (normal user context) and user_dev_t (user dev context). Then, you can define a type transition as above (user_dev_t -> git_exec_t => git_t), and allow only the context git_t access to git_repo_t files. With this setup in place:

- git, as called from within user_dev_t works as normally

- git, as called from user_t, has no defined type transition so will try to access git_repo_t under the user_t context, which will fail.

I don't think SELinux would help much here, since users usually run as unconfined_t. I'd guess typical users also run `sudo <whatever>` without bothering to switch role/type.

Personally I don't user mountains of binary CLI software from random people I've never heard of and don't particularly want to deal with a sandbox. Furthermore, if I really really wanted one I know how to set one up.

Usually I check over things like make files and am immediately concerned if I'm told to run a "build.sh" (especially as root.)

On android the security is kind of an illusion anyway, it's pretty common for apps to either find ways to escape it or trick the user into granting permissions that the apps abuse. The worst offenders are often preinstalled by the hardware vendor anyway and since you don't usually control the OS are impossible to remove.

> it's pretty common for apps to either find ways to escape it

These sound like security bugs, which should obviously be addressed, but "there are bugs" shouldn't be a reason to dismiss the entire goal of isolation-based security. When it comes to the browser, there are obviously occasional issues to do with colouring of visited links, sandbox escapes, information exposure due to speculative CPU execution. Overall though, what's important is that there is a security model and that the implementation issues are addressed.

> Will there be some revolution at some point that encourages people to somehow isolate their commandline activities to different realms, thus limiting the scope of any attack like this?

I hope we can at least put it off until it's a real problem and not turn the world upside down for a largely theoretical one. I also doubt any sort of sandboxing will be effective and practical to run software from untrusted sources.

>The web is obviously strongly based around a security model where a website ultimately can't do much in terms of information access

Recently posted on HN: http://http.jameshfisher.com/2019/05/26/i-can-see-your-local...

Sure, you can create containers or VMs for compilation. It’s just that developers and vim users are a minority so the attacks and consequently the defenses have concentrated on the stuff the majority uses: Microsoft Office, general acquisition and installation of software packages, browsers.

Develop everything in sandboxed containers

s/CLI/desktop