OpenBSD's unveil() | Hacker News Reader

OpenBSD's unveil()

lwn.net

115 pointsmesse51 comments

> There is no reason why your PDF viewer should be able to read your SSH keys, for example.

Well GNOME's evince can read remote files over at least http/https and ftp, eg: evince ftp://remote/foo.pdf. I guess it's just a short step to adding ssh/sftp support. The remote support is implemented using glib's https://developer.gnome.org/gio//2.36/GFile.html#g-file-new-... which has a generic plugin mechanism for URL schemas, although I didn't look into whether ssh is already supported.

:-)

Even then, an ssh subprocess can talk to ssh-agent instead of directly reading keys.

I have some interest in this since I wrote the initial version of ssh integration in qemu, and I have looked at how sshfs is implemented too. For the ssh integration in qemu we used libssh2 (initially, about to be replaced by libssh which is confusingly a different but better library). sshfs on the other hand runs the plain ssh binary in a subprocess and performs its own sftp protocol on top of the ssh connection (with sftp being done inside the sshfs binary).

From a security point of view sshfs is certainly a better approach. However for qemu we were concerned mainly about performance, and some testing that I did at the time indicated that the library approach (libssh2/libssh) would perform better which was why we went that way.

I guess the lesson here is that retrofitting security to existing applications is difficult, or perhaps the lesson is that Linux applications should be split into cooperating processes using lightweight messaging, like QNX or L4.

Even ignoring ssh, the same problem applies to evince + https currently (reading client certificates), and that is certainly not implemented using a subprocess, nor would it be very easy to change that considering how difficult it is to correctly run a subprocess from a multithreaded library using Linux / POSIX APIs.

I'd argue this is a misfeature. Different users have different needs, but I really like knowing that especially my basic "view a file downloaded from the Internet"-applications have a limited attack surface, even if that means it has fewer features. Actually, I'd prefer to have that confidence for all my applications, possibly except necessarily overcomplicated behemoths like web browsers or Emacs.

Wouldn't it be better to expose these other schemas via FUSE mounts anyway? I suppose the main issue is one of UX— how do you make a system "Open file/path" dialog that under the hood is capable of setting up and properly lifecycling something like an sshfs mount? Almost seems like a thing you'd want support for at the systemd service level.

OTOH, doing it as a system dialog that runs safely in its own process feels a lot better to me than building the functionality into every app in a piecemeal way.

Things like sshfs exist to solve this transparently.

You could even create a wrapper that'd mount the remote endpoint to a temporary location, runs your application with that path, then unmounts once your application exits.

This doesn't actually help assuming that unveil(2) persists across a fork (and if it doesn't then that's a back door, and if fork is banned using pledge(2) then you can't use sshfs anyway).

It’s a great concept. But I would NAK the API for Linux:

> Calling unveil() for the first time will "drop a veil" across the entire filesystem, rendering the whole thing invisible to the process, with one exception...

Sorry, but the semantics of calling it once should be similar to the semantics of calling it twice. The first call veils and the second call unveils.

Also, on Linux at least, efficiently implementing “you can only see this subtree” is quite tricky due to races against moving the directories in question around. I wonder how OpenBSD gets around those races.

It feels less inconsistent if you put it like this: every call unveils, but the first one also veils.

Or: every call does the following two things. (1) It ensures that a veil is present. (2) It makes a hole in the veil at the location provided.

Yeah, an easier formulation would be:

noveil(...) to mark pathes we plan to use (fails on veiled pathes), and a subsequent veil() that irreversibly removes access to everything that was not protected by a noveil(...) call between this and the last veil() call.

If a veil() call never comes, well, then we did not restrict access at all and only spammed some kernel structure.

If all you care is protection in case someone gets codeexec in your process, then this would be simpler and give additional features (we can incrementally drop access, instead of only once).

I see an advantage of the unveil(...) in that: Suppose my process cannot irrevocably drop access, because e.g. it anticipates to need to write to some pathes we don't know already. But still, the unveil can help to mitigate stuff like directory traversals: I can't lock (unveil(0,0)), so codeexec is still game over; if my code for late unveiling has bugs it's game over; but if the late unveiling code has no bugs, but the actual file access code is buggy, then this construction will protect me.

Think of it as backward compatible progressive enhancement. You're opting in to veiled FS by making an initial call to unveil a path. The system drops the veil, but only if you indicate that you want to operate in the veiled environment.

Subsequent versions could be veiled by default, requiring calls to `unveil` for everything, but obviously that would break every existing program.

From context I understand the meaning, but what does "NAK" mean here? I'm guessing it's an acronym?

Not acknowledge, e.g. would advise against and, if were the maintainer, would reject the change.

ACK and NAK are used quite a lot in communication protocols, and the usage drift from there.

I like this. It's simple, progressive, delivers a real benefit instantly, cheap and easy to understand.

Entirely the opposite of SELinux.

I'm working on a problem where I have a single executable that is run as a dynamic number of long-running processes where I'd like to restrict each process to a separate directory.

For example, process 1 could only r/w files in "/some/path/1" and process 2 could access "/some/path/2". But the number of processes is dynamic. I might have two or I might have 100. So I need to be able to specify new directories at runtime.

I've been looking at the linux hardening mechanisms but I couldn't find a way to do this with, for example, selinux. With selinux it seems you are mostly able to create system level policies that applied to whole programs. I haven't found a way to provide something like a parameter to change the policy for a given process.

But it looks like this would be very easy to accomplish with unveil(2). This is very interesting work!

Yup, sadly unlike pledge(2) there doesn't seem to be an execveil so you'd have to fork(); unveil(path, perms); unveil(null, null); pledge(...); exec();

Tiny nit. An unveil pledge promise was added so pledging without it is the same as unveil(null, null).

Good point, and makes a lot of sense given the normal pattern of things.

Out of curiosity, what would be the point of restricting child processes to specific directories?

If I trust a binary to read a directory, what's the point of constraining specific processes further?

The only use case I could think of is where the binary itself runs untrusted code from a third party. (e.g. plugins).

unveil also protects you against untrusted code you wrote yourself (and yes, you shouldn’t trust code you wrote yourself. You may know it doesn’t do anything wrong on purpose, but it might be buggy and do something wrong by accident)

Also, if you didn’t write the OS, your untrusted code will call third party code, if it is worth running it at all (it has to communicate results back to the caller. That requires some OS calls, even if only to trigger some semaphore)

If you ever read untrusted data, you should consider the possibility that you’ll be exploited and end up running untrusted code even though you never intended to.

The point of pledge(2) (and unveil which builds on and complements pledge(2)) is to protect against the consequences of human failing: if the software has an accessible exploit, limiting its ability to see the system means the attacker has a much harder time pivoting into something useful.

That's why pledge(2) and unveil(2) are useful despite literally being part of the software it restricts.