Given the Chrome example starting on page 6, here's my guess as to how pledge and unveil will contain Chrome to e.g. protect SSH keys. First, 3 of the 5 Chrome processes are already pledged to disallow filesystem reads. The two remaining ones (RenderProcess and UtilityProcess) can be unveiled to allow directories like
* ~/.config/chromium
* ~/.cache/chromium
* ~/Downloads
* /tmp
* and anything important I don't know of
Additionally, if unveil works like pledge and can be further restricted after e.g. reading files into memory, unveils can then be undone. Anyone know if the following would work to first allow access to /tmp and then revoke that access?
unveil("/tmp", "rw");
/* do some work */
unveil("/tmp", "");
I wouldn't expect your /tmp example to work, because if unveil is anything like pledge, additional calls can only add restrictions, not take them away.
Yes, but the weird thing is that before you call unveil, everything is already unveiled, which is not in sync with the dictionary definition of unveiling. I hope a better name is found.
Your comment made me try to look up the exact semantics of unveil(2). It was a bit hard to find (I could only find something on its predecessor pledgepath), but apparently, unveil doesn't take effect immediately, but only at an invocation of pledge(2) (which usually follows immediately after it). That was not at all clear from TFA.
Given the Chrome example starting on page 6, here's my guess as to how pledge and unveil will contain Chrome to e.g. protect SSH keys. First, 3 of the 5 Chrome processes are already pledged to disallow filesystem reads. The two remaining ones (RenderProcess and UtilityProcess) can be unveiled to allow directories like
Additionally, if unveil works like pledge and can be further restricted after e.g. reading files into memory, unveils can then be undone. Anyone know if the following would work to first allow access to /tmp and then revoke that access?