4 ms·

I'm lumping Linux in that group because my impression is that Linus is ambivalent about security--it seems to be just another feature to him (see http://www.was

I'm lumping Linux in that group because my impression is that Linus is ambivalent about security--it seems to be just another feature to him (see http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/ http://www.washingtonpost.com/sf/business/2015/11/05/net-of-...). Additionally, with most of the popular distros, once I install the OS, I have to spend a bunch of time locking things down before I do anything else, whereas OpenBSD has pretty good defaults that I can build up from. Also, when Ubuntu, one of the most popular Linux distros, started capturing searches by default, that got me questioning their commitment to privacy. That's not to say there aren't distros and contributors to Linux that care deeply about security--clearly there are. I just don't find the overall ecosystem nor the most popular distros nearly as focused on or as trustworthy on security and privacy. And as the stakes get higher with more of our lives going digital and more companies, states, and criminals trying to take advantage of that trend, I worry. As for OpenBSD vs FreeBSD, I've had an easier time getting OpenBSD working on my hardware and OpenBSD seems to me more concerned with, focused on, and practically innovative on security--that is to say, they don't just introduce new security features that can be configured and used by someone smarter than me, the OpenBSD folks work hard to introduce new security tech that's on by default with no special knowledge required by the end user, i.e. pledge, W^X.

nickpsecurity 10y ago
Then modify the claim to say "some Linux kernels/distros" instead of Linux as a whole. Meanwhile, thanks to CompSci, there's Linux's (eg Criswell's SVA-OS) and FreeBSD's (eg CheriBSD on CHERI) that run with way more security than OpenBSD. They push the state of the art. So, it's a mixed bag. OpenBSD is actually no different. The developers care a lot about security and quality. Yet, the mere fact that I see OpenBSD desktops in Google images running shoddy applications shows many OpenBSD users make similar tradeoffs to what you described of Linux camp. It's just the kernel and select userland that gets their attention to quality due to limited staff (and their preferences).
- neerdowell 10y ago
  > Yet, the mere fact that I see OpenBSD desktops in Google images running shoddy applications shows many OpenBSD users make similar tradeoffs to what you described of Linux camp. Are these "shoddy applications" not more secure on OpenBSD due to the various mitigations applied to userland software?
  - nickpsecurity 10y ago
    We don't know. OpenBSD has so little market share that virtually nobody is testing those mitigations. However, many are similar to mitigations developed on other platforms and beaten. So, they'd probably be beaten with effort, too. Don't you love reasoning by precedent? Makes these judgment calls so much easier. :)
    - neerdowell 10y ago
      People are testing the mitigations. For example Qualsys' audit of OpenSMTPD[0] noted that a buffer overflow they found was not exploitable on OpenBSD as even a single byte overflow would smash the stack canary. [0] https://www.qualys.com/2015/10/02/opensmtpd-audit-report.txt https://www.qualys.com/2015/10/02/opensmtpd-audit-report.txt
      - nickpsecurity 10y ago
        That's not trying to break the mitigations: it's simply testing if they stop an exploit which isn't designed to bypass the mitigations. Really easy to pull off. :) Below are examples of a clever scheme for stopping control flow attacks and a successful attempt to breaking it. When I say testing the mitigations, I mean work like what's in the second paper. https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_zhang.pdf https://www.usenix.org/system/files/conference/usenixsecurit... http://www.cs.berkeley.edu/~daw/papers/cfi-sec15.pdf http://www.cs.berkeley.edu/~daw/papers/cfi-sec15.pdf Note: Native Client, which protects Chrome, is a form of Control-flow Integrity. Hence, me using it as an example.
jevinskie 10y ago
An example of Linus' attitude: > Nobody really objected to the patch series as a whole, but Linus hated the name of the configuration option; he asked that it be called CONFIG_LEGACY_VSYSCALLS instead. Or, even better, the change could just be done unconditionally. That led to a fairly predictable response from the PaX developer on how the kernel community likes to hide security problems, to which Linus said: >> Calling the old vdso "UNSAFE" as a config option is just plain stupid. It's a politicized name, with no good reason except for your political agenda. And when I call it out as such, you just spout the same tired old security nonsense. https://lwn.net/Articles/446528/ https://lwn.net/Articles/446528/

nickpsecurity 10y ago

Then modify the claim to say "some Linux kernels/distros" instead of Linux as a whole. Meanwhile, thanks to CompSci, there's Linux's (eg Criswell's SVA-OS) and FreeBSD's (eg CheriBSD on CHERI) that run with way more security than OpenBSD. They push the state of the art. So, it's a mixed bag. OpenBSD is actually no different. The developers care a lot about security and quality. Yet, the mere fact that I see OpenBSD desktops in Google images running shoddy applications shows many OpenBSD users make similar tradeoffs to what you described of Linux camp. It's just the kernel and select userland that gets their attention to quality due to limited staff (and their preferences).

neerdowell 10y ago
> Yet, the mere fact that I see OpenBSD desktops in Google images running shoddy applications shows many OpenBSD users make similar tradeoffs to what you described of Linux camp. Are these "shoddy applications" not more secure on OpenBSD due to the various mitigations applied to userland software?
- nickpsecurity 10y ago
  We don't know. OpenBSD has so little market share that virtually nobody is testing those mitigations. However, many are similar to mitigations developed on other platforms and beaten. So, they'd probably be beaten with effort, too. Don't you love reasoning by precedent? Makes these judgment calls so much easier. :)
  - neerdowell 10y ago
    People are testing the mitigations. For example Qualsys' audit of OpenSMTPD[0] noted that a buffer overflow they found was not exploitable on OpenBSD as even a single byte overflow would smash the stack canary. [0] https://www.qualys.com/2015/10/02/opensmtpd-audit-report.txt https://www.qualys.com/2015/10/02/opensmtpd-audit-report.txt
    - nickpsecurity 10y ago
      That's not trying to break the mitigations: it's simply testing if they stop an exploit which isn't designed to bypass the mitigations. Really easy to pull off. :) Below are examples of a clever scheme for stopping control flow attacks and a successful attempt to breaking it. When I say testing the mitigations, I mean work like what's in the second paper. https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_zhang.pdf https://www.usenix.org/system/files/conference/usenixsecurit... http://www.cs.berkeley.edu/~daw/papers/cfi-sec15.pdf http://www.cs.berkeley.edu/~daw/papers/cfi-sec15.pdf Note: Native Client, which protects Chrome, is a form of Control-flow Integrity. Hence, me using it as an example.

jevinskie 10y ago

An example of Linus' attitude: > Nobody really objected to the patch series as a whole, but Linus hated the name of the configuration option; he asked that it be called CONFIG_LEGACY_VSYSCALLS instead. Or, even better, the change could just be done unconditionally. That led to a fairly predictable response from the PaX developer on how the kernel community likes to hide security problems, to which Linus said: >> Calling the old vdso "UNSAFE" as a config option is just plain stupid. It's a politicized name, with no good reason except for your political agenda. And when I call it out as such, you just spout the same tired old security nonsense. https://lwn.net/Articles/446528/ https://lwn.net/Articles/446528/