21–30 of 36 posts
Awesome! 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 do…
Earlier quoted context omitted.
Not at all, for example you can't implement the ratcheting down semantics of pledge() using seccomp. Say starting with a broader promise set "stdio rpath recvfd", and then dropping to "stdio" after full init. pledge() can also be found in over 85% of OpenBSD's base system.
brings me to the next question: are there linux equivalent ?
[1]: http://www.capsicum-linux.org/ [2]: https://www.freebsd.org/cgi/man.cgi?capsicum(4)
Earlier quoted context omitted.
I think you're refering to systrace. It was removed in OpenBSD 6.0. http://www.citi.umich.edu/u/provos/systrace/
Thanks, that's exactly what I meant. Why was it removed? I did notice pledge(2) first appeared in 5.9 [1] How do other Unices such as Linux deal with this issue (IIRC systrace was ported to other Unices)? Is Pledge ported to other BSDs? [1] http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...
I don't believe pledge is ported to other BSD operating systems, for example FreeBSD uses their own framework, capsicum[1] instead of pledge.
Awesome! 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 do…
Shouldn't it be veil()?
Earlier quoted context omitted.
pledge is seccomp
Not at all, for example you can't implement the ratcheting down semantics of pledge() using seccomp. Say starting with a broader promise set "stdio rpath recvfd", and then dropping to "stdio" after full init. pledge() can also be found in over 85% of OpenBSD's base system.
Earlier quoted context omitted.
Not at all, for example you can't implement the ratcheting down semantics of pledge() using seccomp. Say starting with a broader promise set "stdio rpath recvfd", and then dropping to "stdio" after full init. pledge() can also be found in over 85% of OpenBSD's base system.
brings me to the next question: are there linux equivalent ?
Earlier quoted context omitted.
Not at all, for example you can't implement the ratcheting down semantics of pledge() using seccomp. Say starting with a broader promise set "stdio rpath recvfd", and then dropping to "stdio" after full init. pledge() can also be found in over 85% of OpenBSD's base system.
On linux you can use firejail if it's necessary (or a container if it's needed).
Earlier quoted context omitted.
Shouldn't it be veil()?
The idea is that everything is "veiled" and you "unveil" the stuff you need access to.
Earlier quoted context omitted.
Thanks, that's exactly what I meant. Why was it removed? I did notice pledge(2) first appeared in 5.9 [1] How do other Unices such as Linux deal with this issue (IIRC systrace was ported to other Unices)? Is Pledge ported to other BSDs? [1] http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...
Systrace was removed because it's unsafe for multi-threaded programs because of TOCTOU.
Awesome! 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 do…
Shouldn't it be veil()?