vDSO, 32-bit time, and seccomp

Posted Aug 4, 2019 21:36 UTC (Sun) by roc (subscriber, #30627)
In reply to: vDSO, 32-bit time, and seccomp by quotemstr
Parent article: vDSO, 32-bit time, and seccomp

In practice, security needs vary, seccomp policies vary, and lots of software runs without a seccomp policy at all, so there is no circular deadlock.

Also, many seccomp policies are tailed to the needs of the software they confine, rather than the other way around. Don't tell Chrome or Firefox that they should stop using seccomp policies to sandbox their browser processes because the kernel community needs additional testing of kernel code ... which their browser processes only exercise if they've been compromised.

vDSO, 32-bit time, and seccomp

Posted Aug 5, 2019 0:04 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Chrome actually works just fine with pledge() - http://undeadly.org/cgi?action=article;sid=20160107075227

Raw syscall filtering really is looking like a bad solution.

vDSO, 32-bit time, and seccomp

Posted Aug 5, 2019 0:49 UTC (Mon) by roc (subscriber, #30627) [Link] (1 responses)

Sure, after modifying pledge() to make it work just fine with Chrome. https://marc.info/?l=openbsd-cvs&m=145207222327683&...

But that has nothing to do with this sub-thread, which is about whether capabilities obviate the need for seccomp.

vDSO, 32-bit time, and seccomp

Posted Aug 5, 2019 3:51 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

I honestly don't mind this approach. Fully generalized systems are not always the best solution.