One of the key aspects of hardening the user-space side of an operating system is to provide mechanisms for restricting which parts of the filesystem hierarchy a given process can access. Linux has a number of mechanisms of varying capability and complexity for this purpose, but other kernels have taken a different approach. Over the last few months, OpenBSD has inaugurated a new system call named unveil() for this type of hardening that differs significantly from the mechanisms found in Linux.
Just to try and summarize what this is: The actual unveil() call takes two arguments; a path and a permission string. The first time an application uses it, it loses access to everything except that path and everything underneath it. You can call it again to add more, and you can call it with both arguments NULL to lock it down so you can’t add more. You can also give more specific permissions by passing the path of a subdirectory after a parent directory. Like this:
unveil(“/home/djn”, “rwx”);
unveil(“/home/djn/.ssh”, “”);
unveil(NULL, NULL);
That would allow reading and writing to anything in my home directory except the .ssh folder – and nothing outside it.
The intention is for an application to use this at launch to limit itself to only the files or directories it actually needs, and only start doing complicated things (e.g. parsing a PDF or interpreting JavaScript) after blocking itself off from the rest of the file system. It’s similar to and inspired by pledge(), another “I don’t need access to these features” security call from openBSD.
Edited 2018-10-13 09:33 UTC
It’s a pretty neat design.
Sometimes NIH syndrome is a good thing.
I can see this being a very useful feature and would like to see it implemented on Linux. We have things like AppArmor, but I’ve definitely worked on a few utilities which would benefit from only being able to read/write to a specific directory during the process’s life time.
Imagine if your web browser not only had “private” or “normal” mode, but also would voluntarily open a new window in “restricted” mode. Which would only give it access to its config folder and your Downloads folder. That could be a very simply way to gain a good deal of security with very few lines of code.
Yeah it is pretty neat mechanism for sandboxing, though I would love if it could also grant an external process the right to unveil before locking, so that for instance processes could be launched in read-only mode, and then trigger a firewall like mechanism asking the user if it should be granted write access outside of its application directory.
That would defeat the purpose of this feature and would be just another backdoor.
No, it would allow you to use it as a filesystem firewall, and apply it to ALL applications on launch, instead having it be opt-in only.
Since the applications would need to grant the right to an external process it wouldn’t even undermine the existing usecase.
The point is that after unveil is called with NULL arguments, that process (and I presume processes forked from it since) is forever locked to what it unveiled. To allow an external process to request additional unveils completely undermines it because you’ve just passed the buck on that external process.
Well, for services/daemons you can have something to that effect, albeit messy:
(systemd unit configuration)
– Enable ProtectSystem, ProtectHome
– Set ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=