Hacker News Reader

Comment by bubblethink | Hacker News Reader

The simplicity, and the fact that it forces conscious choices at source/compile time are great, but I wonder if it comes at the cost of flexibility. For anything sufficiently complex, you'll need some configuration after deployment, which selinux handles through policies and labels. In case of unveil, are the file paths hardcoded ? As a simple example, you build chromium with write access to ~/Downloads. What happens if you want to write to ~/New_Downloads ?

View on HN

The paths that you unveil(2) can be hardcoded, set from a command line flag, or parsed in from a config file. What can't be done, however, is arbitrary file access at runtime, as there would be no point at which you could lock unveil or drop the equivalent pledge promise.

For the chrome case, you can currently only access ~/Downloads. This involves changing our habits as /users/. If you need to access files from outside this directory, you need to open a terminal and copy/move files there yourself.

That said, for now.. the chromium package does actually have a external unveil policy in /etc/chromium/unveil.* for each process type (main, gpu, renderer, etc). But that won't necessarily always be there.

> For the chrome case, you can currently only access ~/Downloads. This involves changing our habits as /users/. If you need to access files from outside this directory, you need to open a terminal and copy/move files there yourself.

That is where Apple's approach is probably better: have an entirely separate process bridging the software and specific tasks. The bridge process should be easier to audit (and can have its own restrictions and sanboxing e.g. the only things it needs are to communicate over a socket and see the filesystem), and the browser never gets to see the filesystem.

OpenBSD was already using pledge(2) to protect the different chrome process types, many of them can't access the filesystem directly. Chrome actually has a privsep design, IPC, fd passing over Unix sockets etc.

For example, the GPU and plugin processes can only act on file descriptors received this way:

https://github.com/openbsd/ports/blob/master/www/chromium/pa...

But this alone doesn't protect this "bridge" process itself from accessing the filesystem, this includes your SSH keys, which is where unveil() comes in.

> But this alone doesn't protect this "bridge" process itself from accessing the the filesystem

Of course not, but the point is that the bridge process only comes in contact with the user and a software invoking it, and its sole purpose is to pick a file on the filesystem.

Including your ssh pubkey if that's what you need to select/upload.

Perhaps that's the case, and that's all it's doing, but at least for chromium, it's the main browser process itself currently handling the Open/Save File dialog box.

The chrome case is relatively simpler (UI-wise), but I can see this becoming a major source of friction for a more general server-like setup. If you are setting up a web host with nginx, php-fpm etc., you would likely want a pretty custom permission list (which you do by relabelling in selinux with the various http* type things). In this scheme, it looks like it would mean a recompile, right ?

The path doesn’t need to be hardcoded into the binary, the server could instead unveil those paths you specified as data directories.

> this involves changing our habits as users.

In other words: We have to do what the software requires of us, not the other way round.

I think the point is that security is everyone's responsibility, and everyone will need to chip in.

Reply on news.ycombinator.com