2 ms·

> "OpenBSD's efforts in auditing are not a good compromise. It's not any compromise. It's best practices that do very little to help in the event of an actual b

> "OpenBSD's efforts in auditing are not a good compromise. It's not any compromise. It's best practices that do very little to help in the event of an actual breach." > "... a remote root bug (despite not running as root) that granted a shell ..." This example of yours would begin with an exploit (or feature) of the third-party software, which in turn managed to pivot into an exploitable hole in the kernel/base system in order to gain these escalated privileges. Securing the kernel/base system is where their focus is. I'm not challenging the idea of a blanketing solution like AppArmor, just the notion that the OpenBSD team's efforts are "terrible" and "simply not sufficient".

Zurrrrr 4y ago
> This example of yours would begin with an exploit (or feature) of the third-party software, which in turn managed to pivot into an exploitable hole in the kernel/base system in order to gain these escalated privileges. Securing the kernel/base system is where their focus is. Sure, but the 'base' system doesn't really have anything that people use or that is going to have bugs. It's kind of a copout. > just the notion that the OpenBSD team's efforts are "terrible" and "simply not sufficient". Terrible is maybe a bit strong, but they certainly are not sufficient. There are numerous exploits and exploitation paths that pledge and unveil won't prevent, but MAC/RBAC or other DAC alternatives will.