OpenBSD's filesystem restriction utility is starting to be implemented in the base system. This first large commit from Theo de Raadt is intended to give an example of the intended usage of unveil(2).
"The first call to unveil removes visibility of the entire filesystem from all other filesystem-related system calls (such as open(2), chmod(2) and rename(2)), except for the specified path. Subsequent calls to unveil expose additional views of the filesystem... Attempts to access paths not allowed by unveil will result in an error of EACCES when the flags argument does not match the attempted operation. ENOENT is returned for paths for which no unveil flags are present."
I asssume this means the e.g., open("fully veiled path") will result in -ENOENT before the traditional UNIX file and directory permission bits are even considered.
Unveil is programmatic so the developer can restrict the software to only perform expected behaviors. Like the earlier pledge(2) call OpenBSD introduced a few versions ago. A piece of software may have far more access to the filesystem than is needed. So it can be restricted to the handful of directories or files that it actually needs during execution. And it can progressively relinquish access as it runs and end up in a state where it can't access the filesystem at all.
4 comments
[ 3.1 ms ] story [ 16.3 ms ] thread"The first call to unveil removes visibility of the entire filesystem from all other filesystem-related system calls (such as open(2), chmod(2) and rename(2)), except for the specified path. Subsequent calls to unveil expose additional views of the filesystem... Attempts to access paths not allowed by unveil will result in an error of EACCES when the flags argument does not match the attempted operation. ENOENT is returned for paths for which no unveil flags are present."
I asssume this means the e.g., open("fully veiled path") will result in -ENOENT before the traditional UNIX file and directory permission bits are even considered.