Awesome!<p>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<p><pre><code> * ~/.config/chromium
* ~/.cache/chromium
* ~/Downloads
* /tmp
* and anything important I don't know of
</code></pre>
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?<p><pre><code> unveil("/tmp", "rw");
/* do some work */
unveil("/tmp", "");</code></pre>
The PDF has no introduction section, seems to be aimed at people who already know what it's talking about. Can anyone shed some light on what is the idea here? I honestly don't understand what's going on, apart from that it seems to be some security-related feature (or actually two of them?)
These are the slides from Bob Beck (beck@'s) talk at BSDCan 2018 (Jun 8-9th), apparently missing its first page.. [0]<p><a href="http://www.bsdcan.org/2018/schedule/events/968.en.html" rel="nofollow">http://www.bsdcan.org/2018/schedule/events/968.en.html</a><p>Video should eventually show up on YouTube.<p>[0] <a href="https://twitter.com/bob_beck/status/1005162340956794880" rel="nofollow">https://twitter.com/bob_beck/status/1005162340956794880</a> ;-)
Nice. Back in earlier versions of pledge(2), there was another argument that took paths to allow fs access on, as unveil(2) is doing, but it was never supported/implemented. (see <a href="http://man.openbsd.org/OpenBSD-6.0/pledge.2" rel="nofollow">http://man.openbsd.org/OpenBSD-6.0/pledge.2</a> for the old syntax)