4 ms·

The whole thing about SELinux being so bad it's always just disabled simply isn't true. Red Hat and Fedora have been using it in the default setup for ages, wi

The whole thing about SELinux being so bad it's always just disabled simply isn't true. Red Hat and Fedora have been using it in the default setup for ages, with permissive roles for unknown stuff but things that ship with RHAT locked down, and their support will even help with that. 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.

daneel_w 4y ago
> "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.

daneel_w 4y ago

> "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.