4 ms·
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 acc
by brynet 8y ago
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.
- anoncake 8y ago> 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.
- taborj 8y agoI think the point is that security is everyone's responsibility, and everyone will need to chip in.
- masklinn 8y ago> 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.
- brynet 8y agoOpenBSD 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/patches/patch-services_service_manager_sandbox_openbsd_sandbox_openbsd_cc#L227 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.
- masklinn 8y ago> 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.
- brynet 8y agoPerhaps 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.
- bubblethink 8y agoThe 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 ?
- claudius 8y agoThe path doesn’t need to be hardcoded into the binary, the server could instead unveil those paths you specified as data directories.