5 ms·

Can anyone comment on the OpenBSD security model in 2024? Is it more secure than a minimal linux distro (or one configured to be so) such as Ubuntu Minimal or D

Can anyone comment on the OpenBSD security model in 2024? Is it more secure than a minimal linux distro (or one configured to be so) such as Ubuntu Minimal or Debian Stable? I'm finding it quite difficult to compare OS "security" these days, whatever that means. Everyone seems to have their own crackpot opinions. If anyone with a security background could chime in, I'd be forever grateful.

ranger_danger 3y ago
As far as I know, all of these statements are still true: https://web.archive.org/web/20220227172102/https://madaidans-insecurities.github.io/openbsd.html https://web.archive.org/web/20220227172102/https://madaidans... https://isopenbsdsecu.re/ https://isopenbsdsecu.re/
- yjftsjthsd-h 3y ago
  > OpenBSD has no Mandatory Access Control (MAC) system like AppArmor or SELinux which prevents you from fully locking down user space. Isn't that pledge? And in general, I observe that lots of people are happy to say that OpenBSD's protections are no good, but somehow they can't be bothered to actually show a working exploit.
  - MuffinFlavored 3y ago
    > > OpenBSD has no Mandatory Access Control (MAC) system like AppArmor or SELinux which prevents you from fully locking down user space. Would this have mattered/stopped/mitigated the `xz` problem if systemd spawns opensshd and transiently loads infected .so shared objects?
    - yjftsjthsd-h 3y ago
      I'm not really super confident, but I think the problem is that sshd has to be able to spawn user sessions and those users are generally not supposed to be (meaningfully) confined by selinux or whatever. So I suspect that it wouldn't have helped, because a compromised sshd is necessarily in the prefect place to MitM or forge a session regardless of extra constraints. But take with a grain of salt.
  - sillywalk 3y ago
    AppArmor/SELinux require separate policy files to be written, to describe what an app can/can't do. Pledge/unveil are APIs that developers use to directly restrict what an app can do/can't do.

ranger_danger 3y ago

As far as I know, all of these statements are still true: https://web.archive.org/web/20220227172102/https://madaidans-insecurities.github.io/openbsd.html https://web.archive.org/web/20220227172102/https://madaidans... https://isopenbsdsecu.re/ https://isopenbsdsecu.re/

yjftsjthsd-h 3y ago
> OpenBSD has no Mandatory Access Control (MAC) system like AppArmor or SELinux which prevents you from fully locking down user space. Isn't that pledge? And in general, I observe that lots of people are happy to say that OpenBSD's protections are no good, but somehow they can't be bothered to actually show a working exploit.
- MuffinFlavored 3y ago
  > > OpenBSD has no Mandatory Access Control (MAC) system like AppArmor or SELinux which prevents you from fully locking down user space. Would this have mattered/stopped/mitigated the `xz` problem if systemd spawns opensshd and transiently loads infected .so shared objects?
  - yjftsjthsd-h 3y ago
    I'm not really super confident, but I think the problem is that sshd has to be able to spawn user sessions and those users are generally not supposed to be (meaningfully) confined by selinux or whatever. So I suspect that it wouldn't have helped, because a compromised sshd is necessarily in the prefect place to MitM or forge a session regardless of extra constraints. But take with a grain of salt.
- sillywalk 3y ago
  AppArmor/SELinux require separate policy files to be written, to describe what an app can/can't do. Pledge/unveil are APIs that developers use to directly restrict what an app can do/can't do.