3 ms·

one bug is all it takes

• Analemma_ 3mo ago
  LPEs do need to be fixed, but for most people it's not a threat model they need to worry about.
  • dathinab 3mo ago
    this is a misconception yes, most company settings don't run untrusted code, and OpenBSD is mostly used for servers not employee devices but that doesn't mean LPEs aren't quite relevant, because they matter for pretty much everyone if combined with other vulnerabilities, like RCE, supply chain attack etc. and while RCE are becoming less common, supply chain attacks have been increasingly more common
• bell-cot 3mo ago
  In theory. But real defenses are generally multi-layered. And in that context, a Swiss cheese slice with only one hole is still extremely valuable.
  • JCattheATM 3mo ago
    Well, that's where OpenBSD falls short, it lacks facilities to really enforce defense in depth - even NetBSD has some better features in this regard.
    • yjftsjthsd-h 3mo ago
      I don't think that's true? It runs most services as their own separate users, with pledge+unveil to limit what they can access even more. That's very much depth.
      • bell-cot 3mo ago
        Just popped up, about pledge+unveil - https://news.ycombinator.com/item?id=48851765 https://news.ycombinator.com/item?id=48851765
      • JCattheATM 3mo ago
        It is true. The do surface level protections, but have nothing to really lock down a system. What do they provide that can restrict an attacker who managed to compromise a remote service that wasn't using pledge or unveil? On other OS's, you can set things like append only, limit files being readable by particular processes, whitelist paths or executables from where the system may execute, etc etc etc.
        • yjftsjthsd-h 3mo ago
          > compromise a remote service that wasn't using pledge or unveil? You can't opt out of the protections and then complain that there are no protections > On other OS's, you can set things like append only, https://man.openbsd.org/chflags.1 https://man.openbsd.org/chflags.1 lists such a flag > limit files being readable by particular processes, That's trivial by setting group/world permissions on any unix-like. > whitelist paths or executables from where the system may execute, So, https://why-openbsd.rocks/fact/noexec/ https://why-openbsd.rocks/fact/noexec/ ? > etc etc etc. Etc etc etc.
          • JCattheATM 3mo ago
            > You can't opt out of the protections and then complain that there are no protections Sometimes you don't have a choice in running software that doesn't use the 'protections' an obscure OS offers. If someone wants to run Oracle, pledge and unveil is irrelivant, as where other security solutions can still protect Oracle without requiring opt-in, and to a far greater extent. > https://man.openbsd.org/chflags.1 https://man.openbsd.org/chflags.1 lists such a flag It's too blunt, it's an all or nothing approach. You have no way to say process A can append only, but privileged process b should have no write access at all. > That's trivial by setting group/world permissions on any unix-like. Only in the bluntest of terms. There is no way to allow, say, a webserverto have read access to a file while not allowing a cat processes, spawned as a subprocess of that webserver process, to not have access. > So, https://why-openbsd.rocks/fact/noexec/ https://why-openbsd.rocks/fact/noexec/ ? No, not even close. I mean allowing user a to run /bin/ls to execute while not having access to execute /bin/rm, and at the same time allowing user b to execute both, and user c to run /bin/rm but not /bin/ls > Etc etc etc. No, not really, since you didn't make any point that were not based on misunderstandings.
• Brian_K_White 3mo ago
  Yet it is not true that 1 bug is the same as 100 bugs. There is no such thing as 0 bugs, and fewer is better than more.