5 ms·

What do you mean?

by jooize 6y ago

What do you mean?

woodruffw 6y ago
OpenBSD has historically been eager to add new security mitigations without explaining their intended threat model. Here's an excellent talk (in website form) on the subject: https://isopenbsdsecu.re/about/ https://isopenbsdsecu.re/about/
- ta17711771 6y ago
  In the face of the Linux kernel not taking care of known exploits, regardless of their usability, I'll take it.
- bawolff 6y ago
  I dont think that website is very compelling. It claims a bunch of things as not good practise, and then asserts without evidence or example that openbsd does them. Quite frankly it reads like someone with an axe to grind against openbsd.
  - woodruffw 6y ago
    > I dont think that website is very compelling. It claims a bunch of things as not good practise, and then asserts without evidence or example that openbsd does them. Here's a material example: OpenBSD has expended considerable effort into removing ROP gadgets from their compilation products[1]. As the website documents[2], these efforts haven't made a single exploit harder to write. GCC even removed their (mostly equivalent) ROP mitigation approach, documenting it as "fairly ineffective" and "lur[ing] developers to the land of false security"[3]. (Another good example is PID randomization: OpenBSD added this over 20 years ago as part of their "randomize anything that can be randomized" approach. It's never had any real positive security impact, and has made other PID-based vulnerabilities more viable.) [1]: https://www.openbsd.org/papers/eurobsdcon2018-rop.pdf https://www.openbsd.org/papers/eurobsdcon2018-rop.pdf [2]: https://isopenbsdsecu.re/mitigations/rop_removal/ https://isopenbsdsecu.re/mitigations/rop_removal/ [3]: https://patchwork.ozlabs.org/project/gcc/patch/CAFULd4ZL-wa3wBaH4cNmvW=nxMYDgXtybinE4sg5EmsAgtasMA@mail.gmail.com/ https://patchwork.ozlabs.org/project/gcc/patch/CAFULd4ZL-wa3...
    - beachhead 6y ago
      Where are all the OpenBSD exploits that bypass these mitigations? Serious question.
    - sanxiyn 6y ago
      I agree some OpenBSD security mitigations are dubious, but if I am forced to choose between Linux (too little) and OpenBSD (too much), it seems to me OpenBSD is definitely preferrable. (Of course, the best is to implement only effective ones.) Do you disagree?
      - zokula 6y ago
        OpenBSD is mostly security snake oil. It's just a tool for masturbating monkeys.
      - woodruffw 6y ago
        I think that Linux is a security mess in its own ways. That being said, I think Linux’s guts get far more attention than OpenBSD’s do, and that the (fewer) mitigations that Linux chooses to implement are much better supported by both information on real-world attacks and by the literature. Given that, I have a slight preference for Linux. But that shouldn’t be taken as praise.
    - IcePic 6y ago
      at the time, lots and lots of scripts would place things in /tmp/scriptname-$PID so you could race them, since you can know where it will write things, other scripts would use PID for random which is equally bad, especially for things that run from rc scripts at startup, so I would say "nothing was gained" is a bit of a stretch. After a while, mktemp got more usage (which is good) and $RANDOM became available for scripts and so forth, but the situation was quite bad 20+ years ago as far as vendor installation scripts went. Perhaps exactly noone was saved on OpenBSD because few installed linux-compat Netscape 1.1N for i386 with a bad installation script while having adversarial users logged in, but there is no reason to be equally bad as the then-more-popular OSes who did see /tmp races being won by users.
  - asveikau 6y ago
    I think the review on that website is actually more mixed than "axe to grind". I just spent some time reading the "mitigations" section. Some mitigations are criticized as questionable or easily defeated, but others are praised for a good implementation. At any rate, I think some people may forget what stock Linux distros or even a commercial *nix install used to look like at the default install, before people like the OpenBSD folks raised awareness of some of these issues. In the late 90s I recall default installs elsewhere that had a bunch of ports open and no firewall right out of the box in a default install. In the same timeframe OpenBSD was making a bit of a PR-ish stink about a secure default install. In the same timeframe OpenSSH came on the scene. But honestly, there are a few things that OpenBSD is only really just starting to get really right in the last few years. syspatch and pkg_add-able binary updates in the stable branch are two that come to mind. Also sysupgrade; I used to dread upgrading OpenBSD [xkcd had the joke about it leading to shark attacks], but now it's really simple.
    - beachhead 6y ago
      If you look at some of the comments, sources, and just the attitude of the guy that put this together it seems he does have an axe to grind. It kinda says so in the about section. I think if you dive into the mitigations section without looking at that it seems less like that because he ends up having to admit some of them are decent ideas... try as he might to come up with ways in which they're not. There are plenty of OpenBSD users going around talking nonsense but this "systematic evaluation" is not an actual systematic evaluation. I especially like the part where it lists people who helped but it's all redacted. All of this "research" came from google and twitter. I'd like to see some bypasses to OpenBSD's mitigations and perhaps some ideas and/or code to help improve them or implement ones that these folks say work better. If they're all so bad then it shouldn't be hard for someone like the author or so called security experts he quoted to do these things. Yeah, maybe no one is going to pay for that work to be done... that seems to always be the response when someone asks for proof, code, etc. No one has the time. They sure spend enough time making websites, blog posts, and tweeting about it though.
      - Accacin 6y ago
  - lmm 6y ago
    Is anyone denying that OpenBSD's mitigations follow those practices? You can look at OpenBSD's own presentations about, say, pledge, and it seems like that website's characterisation is fair: no characterisation of what the threat model is, what vulnerabilities this is intended to make impossible, and no assessment of whether it actually succeeds in this.
    - bawolff 6y ago
      Im not super familar with openbsd or pledge, but isn't pledge just an extension of standard privledge segregation stuff? People have been using privledge segregation for decades at this point.
      - lmm 6y ago
        Privilege separation has indeed been in use for decades, but the same criticisms apply to it (and indeed it seems to mostly be an OpenBSD technique).
    - IcePic 6y ago
      And I think it is rather obvious. Pledge lessens the amount of syscalls available to a program after it has called pledge(), so the threats it means to protect against is if someone tries to trick "ls" into opening a socket and doing network calls for instance, if ls pledges that from this point onward it will only do disk reads via the fs and output via text console. Just as a guide telling you to "chmod 600 webserver.key" doesn't really state anymore that it tries to protect non-webserver access to the https key, because it is implied that removing random access to the key (or to non-useful syscalls in the case of pledge) means the threat was unexpected reads of the key by someone who shouldn't be allowed to do just that. No assessments would be found to say "chmod'ing 600 removes 56% of the unexpected read attempts, Posix ACLs 9% more, apparmor another 14%, and correct SELinux tags will stop upto 96% of the keyfile reads by the wrong user". If my wildly invented numbers were right would anyone suggest only using SELinux and leave keyfiles at chmod 777? One can then put up an angry webpage claiming people who chmod their keys are crap at security, it is uneffective, no listing of what it even was meant to protect against and of course no hard numbers to it. But 0600 would help you the day some junior admin turned off selinux on the webserver because random HOWTO said colorls works better with it off.
deleted 6y ago
[deleted]
moviuro 6y ago
See https://www.openbsd.org/security.html https://www.openbsd.org/security.html and https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html Some snippets: > OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more uncompromising view towards increased security than most vendors are able to. We can make changes the vendors would not make. Also, since OpenBSD is exported with cryptography, we are able to take cryptographic approaches towards fixing security problems. > ASLR: OpenBSD 3.4 [Nov 2003] was the first widely used operating system to provide it by default. > W^X: First used for sparc, sparc64, alpha, and hppa in OpenBSD 3.3. Strictly enforced by default since OpenBSD 6.0: a program can only violate it if the executable is marked with PT_OPENBSD_WXNEEDED and it is located on a filesystem mounted with the wxallowed mount(8) option. > Kernel relinking at boot: the .o files of the kernel are relinked in random order from a link-kit, before every reboot. This provides substantial interior randomization in the kernel's text and data segments for layout and relative branches/calls. Basically a unique address space for each kernel boot, similar to the userland fork+exec model described above but for the kernel. Theo de Raadt, June 2017.

What do you mean?

by jooize 6y ago

What do you mean?

OpenBSD has historically been eager to add new security mitigations without explaining their intended threat model. Here's an excellent talk (in website form) on the subject: https://isopenbsdsecu.re/about/ https://isopenbsdsecu.re/about/

ta17711771 6y ago
In the face of the Linux kernel not taking care of known exploits, regardless of their usability, I'll take it.
bawolff 6y ago
I dont think that website is very compelling. It claims a bunch of things as not good practise, and then asserts without evidence or example that openbsd does them. Quite frankly it reads like someone with an axe to grind against openbsd.
- woodruffw 6y ago
  > I dont think that website is very compelling. It claims a bunch of things as not good practise, and then asserts without evidence or example that openbsd does them. Here's a material example: OpenBSD has expended considerable effort into removing ROP gadgets from their compilation products[1]. As the website documents[2], these efforts haven't made a single exploit harder to write. GCC even removed their (mostly equivalent) ROP mitigation approach, documenting it as "fairly ineffective" and "lur[ing] developers to the land of false security"[3]. (Another good example is PID randomization: OpenBSD added this over 20 years ago as part of their "randomize anything that can be randomized" approach. It's never had any real positive security impact, and has made other PID-based vulnerabilities more viable.) [1]: https://www.openbsd.org/papers/eurobsdcon2018-rop.pdf https://www.openbsd.org/papers/eurobsdcon2018-rop.pdf [2]: https://isopenbsdsecu.re/mitigations/rop_removal/ https://isopenbsdsecu.re/mitigations/rop_removal/ [3]: https://patchwork.ozlabs.org/project/gcc/patch/CAFULd4ZL-wa3wBaH4cNmvW=nxMYDgXtybinE4sg5EmsAgtasMA@mail.gmail.com/ https://patchwork.ozlabs.org/project/gcc/patch/CAFULd4ZL-wa3...
  - beachhead 6y ago
    Where are all the OpenBSD exploits that bypass these mitigations? Serious question.
  - sanxiyn 6y ago
    I agree some OpenBSD security mitigations are dubious, but if I am forced to choose between Linux (too little) and OpenBSD (too much), it seems to me OpenBSD is definitely preferrable. (Of course, the best is to implement only effective ones.) Do you disagree?
    - zokula 6y ago
      OpenBSD is mostly security snake oil. It's just a tool for masturbating monkeys.
    - woodruffw 6y ago
      I think that Linux is a security mess in its own ways. That being said, I think Linux’s guts get far more attention than OpenBSD’s do, and that the (fewer) mitigations that Linux chooses to implement are much better supported by both information on real-world attacks and by the literature. Given that, I have a slight preference for Linux. But that shouldn’t be taken as praise.
  - IcePic 6y ago
    at the time, lots and lots of scripts would place things in /tmp/scriptname-$PID so you could race them, since you can know where it will write things, other scripts would use PID for random which is equally bad, especially for things that run from rc scripts at startup, so I would say "nothing was gained" is a bit of a stretch. After a while, mktemp got more usage (which is good) and $RANDOM became available for scripts and so forth, but the situation was quite bad 20+ years ago as far as vendor installation scripts went. Perhaps exactly noone was saved on OpenBSD because few installed linux-compat Netscape 1.1N for i386 with a bad installation script while having adversarial users logged in, but there is no reason to be equally bad as the then-more-popular OSes who did see /tmp races being won by users.
- asveikau 6y ago
  I think the review on that website is actually more mixed than "axe to grind". I just spent some time reading the "mitigations" section. Some mitigations are criticized as questionable or easily defeated, but others are praised for a good implementation. At any rate, I think some people may forget what stock Linux distros or even a commercial *nix install used to look like at the default install, before people like the OpenBSD folks raised awareness of some of these issues. In the late 90s I recall default installs elsewhere that had a bunch of ports open and no firewall right out of the box in a default install. In the same timeframe OpenBSD was making a bit of a PR-ish stink about a secure default install. In the same timeframe OpenSSH came on the scene. But honestly, there are a few things that OpenBSD is only really just starting to get really right in the last few years. syspatch and pkg_add-able binary updates in the stable branch are two that come to mind. Also sysupgrade; I used to dread upgrading OpenBSD [xkcd had the joke about it leading to shark attacks], but now it's really simple.
  - beachhead 6y ago
    If you look at some of the comments, sources, and just the attitude of the guy that put this together it seems he does have an axe to grind. It kinda says so in the about section. I think if you dive into the mitigations section without looking at that it seems less like that because he ends up having to admit some of them are decent ideas... try as he might to come up with ways in which they're not. There are plenty of OpenBSD users going around talking nonsense but this "systematic evaluation" is not an actual systematic evaluation. I especially like the part where it lists people who helped but it's all redacted. All of this "research" came from google and twitter. I'd like to see some bypasses to OpenBSD's mitigations and perhaps some ideas and/or code to help improve them or implement ones that these folks say work better. If they're all so bad then it shouldn't be hard for someone like the author or so called security experts he quoted to do these things. Yeah, maybe no one is going to pay for that work to be done... that seems to always be the response when someone asks for proof, code, etc. No one has the time. They sure spend enough time making websites, blog posts, and tweeting about it though.
    - Accacin 6y ago
- lmm 6y ago
  Is anyone denying that OpenBSD's mitigations follow those practices? You can look at OpenBSD's own presentations about, say, pledge, and it seems like that website's characterisation is fair: no characterisation of what the threat model is, what vulnerabilities this is intended to make impossible, and no assessment of whether it actually succeeds in this.
  - bawolff 6y ago
    Im not super familar with openbsd or pledge, but isn't pledge just an extension of standard privledge segregation stuff? People have been using privledge segregation for decades at this point.
    - lmm 6y ago
      Privilege separation has indeed been in use for decades, but the same criticisms apply to it (and indeed it seems to mostly be an OpenBSD technique).
  - IcePic 6y ago
    And I think it is rather obvious. Pledge lessens the amount of syscalls available to a program after it has called pledge(), so the threats it means to protect against is if someone tries to trick "ls" into opening a socket and doing network calls for instance, if ls pledges that from this point onward it will only do disk reads via the fs and output via text console. Just as a guide telling you to "chmod 600 webserver.key" doesn't really state anymore that it tries to protect non-webserver access to the https key, because it is implied that removing random access to the key (or to non-useful syscalls in the case of pledge) means the threat was unexpected reads of the key by someone who shouldn't be allowed to do just that. No assessments would be found to say "chmod'ing 600 removes 56% of the unexpected read attempts, Posix ACLs 9% more, apparmor another 14%, and correct SELinux tags will stop upto 96% of the keyfile reads by the wrong user". If my wildly invented numbers were right would anyone suggest only using SELinux and leave keyfiles at chmod 777? One can then put up an angry webpage claiming people who chmod their keys are crap at security, it is uneffective, no listing of what it even was meant to protect against and of course no hard numbers to it. But 0600 would help you the day some junior admin turned off selinux on the webserver because random HOWTO said colorls works better with it off.

deleted 6y ago

[deleted]

moviuro 6y ago

See https://www.openbsd.org/security.html https://www.openbsd.org/security.html and https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html Some snippets: > OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more uncompromising view towards increased security than most vendors are able to. We can make changes the vendors would not make. Also, since OpenBSD is exported with cryptography, we are able to take cryptographic approaches towards fixing security problems. > ASLR: OpenBSD 3.4 [Nov 2003] was the first widely used operating system to provide it by default. > W^X: First used for sparc, sparc64, alpha, and hppa in OpenBSD 3.3. Strictly enforced by default since OpenBSD 6.0: a program can only violate it if the executable is marked with PT_OPENBSD_WXNEEDED and it is located on a filesystem mounted with the wxallowed mount(8) option. > Kernel relinking at boot: the .o files of the kernel are relinked in random order from a link-kit, before every reboot. This provides substantial interior randomization in the kernel's text and data segments for layout and relative branches/calls. Basically a unique address space for each kernel boot, similar to the userland fork+exec model described above but for the kernel. Theo de Raadt, June 2017.