6 ms·

Why isn't an obvious choice? What other system has enabled by default the following security mitigations: * Enforced W^X in the kernel on i386/amd64/sparc64.

Why isn't an obvious choice? What other system has enabled by default the following security mitigations: * Enforced W^X in the kernel on i386/amd64/sparc64. * Enforced W^X userland as of 6.0 (..exceptions must have a special ELF PT_* flag and be on a filesystem mounted wxallowed). * arc4random(3), which backs rand(3), random(3), and drand48(3), with an audited base/ports tree. Software must opt-in to deterministic broken POSIX behavior. * Stack protector (..which OpenBSD pushed into wide adoption). * bcrypt password hashes only, with an automatically selected rounds value based on system performance. * PIE by default for base and ports. * Static-PIE for self-relocating static binaries. * SROP (sigreturn(2) oriented programming) mitigation by default. * C shared library re-ordering at boot time, i.e: libc.so is re-linked at boot time so objects are randomly ordered. * System-wide sandboxing (pledge(2)) of a large percentage of the userland, incl. privileged part of the X server, most networking facing daemons included (..with increasingly reduced pledges, thanks to the next part..). * Privilege dropping and separation for most of the base system as a matter of policy, new stuff doesn't get enabled without it. Plenty of other innovations in programming interfaces, widely adopted outside of OpenBSD.. which leads me to disbelieve your claims of non-uniformity in opinion of any reputable 'security pro'. http://www.openbsd.org/innovations.html http://www.openbsd.org/innovations.html

tptacek 10y ago
Here's something I wrote a few years back here. What's changed in the 6 years following is that I think we're down to just two approaches, unless you feel OpenBSD is assimilating the MAC approach. https://news.ycombinator.com/item?id=1997385 https://news.ycombinator.com/item?id=1997385
- snaky 10y ago
  In [1] Ron Wilson examines two models almost in the same terms ("Internal security" and "Guarding the perimeter"), but the third is different > That brings us to our third—and today, still experimental—alternative: deep learning. Connect the critical state variables of the system to a deep-learning neural network. Train the network with a blend of normal operation, known attacks, and randomly injected faults. You may never know how the resulting network operates, and you can’t prove that the network is sufficient or even correct. But in complex systems it is likely to out-perform human-devised rule lists [1] http://systemdesign.altera.com/system-security-a-model-from-medieval-history/ http://systemdesign.altera.com/system-security-a-model-from-...
- ghshephard 10y ago
  I read through your 2010 post three or four times - but it doesn't really seem to be as relevant to 2016 OpenBSD. 2016 OpenBSD assumes that there will be errors in the code, and furthermore, there will be errors that have downstream security effects that the authors can't envision today. A lot of the thinking around pledge (2) is that behavior that an SElinux MAC audit would record, and therefore allow moving forward, should not be allowed. The entire operating systems seems to be designed in the belief that there is no way to write bug-free applications, so at every level, the operating system, and kernel, should be designed with the expectation that an attacker has broken applications in a manner not envisioned by the application writers of the time. As such, a number of attack/bugs found in other operating systems, don't impact OpenBSD because they were forward looking. I'm wondering if you've had a chance to review the change in thinking that the OpenBSD organization has had in the last 6 years, and how it might impact your original 2010 post?
  - danieldk 10y ago
    A lot of the thinking around pledge (2) is that behavior that an SElinux MAC audit would record, and therefore allow moving forward, should not be allowed. There are important differences. pledge requires you to modify an application. SELinux can sandbox any application, including untrusted applications (see the use of SELinux in Android). Since SELinux is external to the application, a system administrator can specify/refine a policy, while pledge calls are compiled in. As such, a number of attack/bugs found in other operating systems, don't impact OpenBSD because they were forward looking. This vision is not exclusive to OpenBSD. Red Hat Enterprise Linux has included many of the same mitigation techniques for a long time (starting at RHEL 3 in 2003). Moreover, they have shipped SELinux, which is arguably more powerful than pledge since RHEL 4 in 2005. (I don't want to discredit the work of the OpenBSD developers, which is great. I just want to point out that there are Linux distributions with similar features, wider hardware support, and wider vendor support. Many OpenBSD supporters just seem to ignore work by others in order to push their favorite system.)
    - ghshephard 10y ago
      Yes - it's a good point that pledge(2) requires that you modify the application, and, that's too some degree a downside of the model. On the flipside, you can't turn off pledge(2) - which has been the default behavior of every (admittedly junior) sysadmin I know who ran into a problem with SELinux that I've seen. The point I was also trying to make (and I'm not sure if I was successful) was that the use of pledge sometimes results in the application being modified to prevent overly permissive behavior (http://www.tedunangst.com/flak/post/going-full-pledge http://www.tedunangst.com/flak/post/going-full-pledge) - whereas in the SELinux "audit" mode, that permissive behavior would be noted, and permitted. I"m just wondering whether tptacek has rethought his comment from 2010 about OpenBSD " its model depends on shipping bug-free distributions " given a lot of success OpenBSD has had in the past several years dodging exploits that resulted from bug-present distribution issues, that its OS compartmentalization approach has successfully avoided.
nickpsecurity 10y ago
You just argued that OpenBSD is more secure because it has specific feature set. You didnt prove these are the right combo of features, that they in solo/combo work against strong attackers (instead of obscurity advantage), or even strongest ones of their respective classes (they're not). You started with OpenBSD's features, accepted the claims as fact, ignored all other tech/requirements, and then asked other party to prove their claim with evidence. Wrong way to do an argument for or even against OpenBSD. You need to establish requirements for security in many areas, features/practices to support those, assurance they work, and then what each OS or system possesses. OpenBSD has only partly done this so I doubt uou have. I look forward to you posting that analysis for OpenBSD and its preferred hardware.
- notaplumber 10y ago
  > You didnt prove these are the right combo of features, that they in solo/combo work against strong attackers (instead of obscurity advantage), or even strongest ones of their respective classes (they're not) Security mitigations work best in combinations, the entire purpose is to make it as hard as possible to attack the system.. suggesting OpenBSD's mitigations aren't the strongest in their class clearly needs some proof on your part, but I don't expect you'll deliver. > You started with OpenBSD's features, accepted the claims as fact. I stated the facts, because I'm aware of and closely followed their development, having tested them. I accepted no claims as "facts". You can easily verify everything I've said, OpenBSD is open source.. and shocking, they pioneered that too.. having created anoncvs. Not much left to reply to in your post, because you're just grasping at proverbial straws.
  - nickpsecurity 10y ago
    "Security mitigation work best in combinations," Exactly the kind of meaningless statement I was talking about. You've neither proven they work in isolation nor shown they're a strong combination against determined attackers. Almost all of those people are hitting Windows, Linux, iOS, and Android due to market share. Im not sure we've even seen thorough test of OpenBSD's defenses. "suggesting OpenBSD's mitigations aren't the strongest in their class clearly needs some proof on your part" Let's try a few memory or stack issues. SPARK can prove the absence of most of them. Concurrent Pascal and Eiffel could for concurrency. Rust can for dynamic memory and concurrency. SAFEcode does for many C-related errors. Example uses are in Muen, Redox, and SVA-OS. Softbound + CETS goes further with total spatial and temporal safety for C but not in OS's yet. These are all stronger than OpenBSD techniques for similar use cases. Different tradeoffs involved in using them but definitely stronger. I mean, full safety without GC is strongest you can get in memory errors. Although SPIN OS did it in Modula-3 with GC and type-safe linking too. "and shocking, they pioneered that too.. having created anoncvs." Your lack of research is apparent as the first, secure OS with source was Burroughs B5000. It was proprietary but shipped source. Had stack checks, bounds checking, pointer protection, OS in high-level language, compile-time checks for function calls, and run-time checks for invalid arguments. Started high-assurance security by addressing root causes of most known issues... in 1961. It's also not easy to figure out OpenBSD security effectiveness looking at source. The safer languages like Modula-3 or techniques of B5000/JX-OS/Genode are easy to follow since they are simple & fully preventative. Verify that then the rest inherits its properties if used or interfaced certain way. Not so with OpenBSD's scattered mechanisms: requires much more analysis given use of C and stuff in kernel mode. Finally, bringing up AnonCVS, you might want to look at David Wheeler's Software Configuration Management security page to see what high-security requires in that. Shapiro's OpenCM (in architecture) or competing Aegis (features) were ahead in many ways with OpenBSD's SCM tactics not registering a blip due to missing requirements on Wheeler et al's lists. I even watched them replaced a distribution tool known to resist NSA per Snowden leaks for a simpler, but unproven, one. OpenBSD has proven great at configuration, code quality, and minimalism. Burden of proof is still on it in terms of security engineering practices vs other methods or OS's. It's never been proven from requirements to methods to results. Fine with me as it has it's uses, esp where 0-days being low is top priority. Best not to pretend it is something it's not vs making the case with evidence as I described.
ryuuchin 10y ago
Linux with grsecurity is a pretty obvious alternative. There are distros which include grsecurity patched kernels in their repo (or use it by default) although going this route over a self-compiled one does loose out on a few security features. Some grsecurity features are supersets of the features you listed such as the W^X protections (which I might add have been in PaX for quite some time now). While the situation certainly isn't perfect with getting more packages using PIE at least a number of important packages are now built with that by default. Arch Linux compiles all packages in its repo's with stack protection AFAIK and at least on Arch it's very easy to recompile things to suit your (performance) needs/threat model. Perhaps OpenBSD offers more of these compiled protections by default in its base/ports but you can still get these options on Linux if you're willing to put a little effort in or use the right distro for your needs. OpenBSD is less of an obvious choice when you look at what you can do with grsecurity if you put a bit of effort into it both on the side of grsecurity (RBAC) and setting up your distro. You can't just wave your hand and dismiss grsecurity because you believe it to be non-standard/non-upstream or somehow incomprehensible/complicated. It's not about what's enabled by default, it's about how much security/protection/defense in depth I can get from it and arguably you get more from Linux w/grsecurity.
- ben_bai 10y ago
  The point is "optional security is bad security" because when stuff doesn't work it gets turned off. So _nobody_ turns those things on. In OpenBSD all the mitigations are enabled all the time, and with pledge beeing the responsibility of the coder, no extra effort needed from the sys admin.
  - ryuuchin 10y ago
    I was just trying to make a point that OpenBSD is not always the best choice for all possible use cases to expand upon tptacek's post a little. In may be for someone uninformed or lazy but my argument is if you're willing to put in a little effort you can get a system which is arguably better from a security and defense in depth standpoint than OpenBSD. There are obvious benefits to both but I don't think that grsecurity is something which can be dismissed as easily as saying nobody uses it.
danieldk 10y ago
Red Hat Enterprise Linux (and thus CentOS) has many of those features: https://access.redhat.com/articles/65299 https://access.redhat.com/articles/65299 Also, it provides MAC per SELinux.
eugeneionesco 10y ago
>What other system has enabled by default the following security mitigations Let's see. >Enforced W^X in the kernel Linux, OS X, Windows >Enforced W^X userland as of 6.0 Linux >Stack protector (..which OpenBSD pushed into wide adoption). Literally every other OS out there has stack protector, and it was Windows pushing it to wide adoption >PIE by default for base and ports. Linux >Static-PIE for self-relocating static binaries. Linux >SROP (sigreturn(2) oriented programming) mitigation by default. Useless "mitigation", can be easily bypassed with no effort >C shared library re-ordering at boot time, i.e: libc.so is re-linked at boot time so objects are randomly ordered. Useless mitigation, can be easily bypassed with no effort >System-wide sandboxing (pledge(2)) of a large percentage of the userland Large percentage? I disagree, it's more like 10%.
- marios 10y ago
  The key word is "by default". I have no idea whether the Linux kernel that each distro ships enforced W^X. For userland, the effort is undergoing. For instance, I recently packaged a C application for Debian. Then, by sheer luck I stumbled upon the Debian Wiki[0] where it explained that one needs to specify "DEB_BUILD_MAINT_OPTIONS = hardening=+all" to enable compiler hardening options. Why isn't that on by default ? The wiki asks the reader to enable hardening if the program handles untrusted data. Doesn't that apply to 99% of the applications out there ? Even it only reads its own configuration file, there is a possibility of a bug in the parser. Why take the risk at all ? Enable it by default for everyone and be done with it. Regarding the pledge(2) sandboxing, pretty much every userland application in the base install of OpenBSD where is makes sense to sandbox is using pledge. Ports/packages are another story entirely. [0] https://wiki.debian.org/Hardening#Using_Hardening_Options https://wiki.debian.org/Hardening#Using_Hardening_Options
  - ryuuchin 10y ago
    Arch Linux enables -fstack-protector-strong last I checked by default. I admit Debian often drags it feet on some things like this but I think Ubuntu has enabled it for a number of packages as well.
nwmcsween 10y ago
iirc openbsd uses fno-strict-aliasing in the base system because the code is buggy.
cm3 10y ago
> What other system has enabled by default the following security mitigations HardenedBSD already ticks off most points and is actively working on the rest.

tptacek 10y ago

Here's something I wrote a few years back here. What's changed in the 6 years following is that I think we're down to just two approaches, unless you feel OpenBSD is assimilating the MAC approach. https://news.ycombinator.com/item?id=1997385 https://news.ycombinator.com/item?id=1997385

snaky 10y ago
In [1] Ron Wilson examines two models almost in the same terms ("Internal security" and "Guarding the perimeter"), but the third is different > That brings us to our third—and today, still experimental—alternative: deep learning. Connect the critical state variables of the system to a deep-learning neural network. Train the network with a blend of normal operation, known attacks, and randomly injected faults. You may never know how the resulting network operates, and you can’t prove that the network is sufficient or even correct. But in complex systems it is likely to out-perform human-devised rule lists [1] http://systemdesign.altera.com/system-security-a-model-from-medieval-history/ http://systemdesign.altera.com/system-security-a-model-from-...
ghshephard 10y ago
I read through your 2010 post three or four times - but it doesn't really seem to be as relevant to 2016 OpenBSD. 2016 OpenBSD assumes that there will be errors in the code, and furthermore, there will be errors that have downstream security effects that the authors can't envision today. A lot of the thinking around pledge (2) is that behavior that an SElinux MAC audit would record, and therefore allow moving forward, should not be allowed. The entire operating systems seems to be designed in the belief that there is no way to write bug-free applications, so at every level, the operating system, and kernel, should be designed with the expectation that an attacker has broken applications in a manner not envisioned by the application writers of the time. As such, a number of attack/bugs found in other operating systems, don't impact OpenBSD because they were forward looking. I'm wondering if you've had a chance to review the change in thinking that the OpenBSD organization has had in the last 6 years, and how it might impact your original 2010 post?
- danieldk 10y ago
  A lot of the thinking around pledge (2) is that behavior that an SElinux MAC audit would record, and therefore allow moving forward, should not be allowed. There are important differences. pledge requires you to modify an application. SELinux can sandbox any application, including untrusted applications (see the use of SELinux in Android). Since SELinux is external to the application, a system administrator can specify/refine a policy, while pledge calls are compiled in. As such, a number of attack/bugs found in other operating systems, don't impact OpenBSD because they were forward looking. This vision is not exclusive to OpenBSD. Red Hat Enterprise Linux has included many of the same mitigation techniques for a long time (starting at RHEL 3 in 2003). Moreover, they have shipped SELinux, which is arguably more powerful than pledge since RHEL 4 in 2005. (I don't want to discredit the work of the OpenBSD developers, which is great. I just want to point out that there are Linux distributions with similar features, wider hardware support, and wider vendor support. Many OpenBSD supporters just seem to ignore work by others in order to push their favorite system.)
  - ghshephard 10y ago
    Yes - it's a good point that pledge(2) requires that you modify the application, and, that's too some degree a downside of the model. On the flipside, you can't turn off pledge(2) - which has been the default behavior of every (admittedly junior) sysadmin I know who ran into a problem with SELinux that I've seen. The point I was also trying to make (and I'm not sure if I was successful) was that the use of pledge sometimes results in the application being modified to prevent overly permissive behavior (http://www.tedunangst.com/flak/post/going-full-pledge http://www.tedunangst.com/flak/post/going-full-pledge) - whereas in the SELinux "audit" mode, that permissive behavior would be noted, and permitted. I"m just wondering whether tptacek has rethought his comment from 2010 about OpenBSD " its model depends on shipping bug-free distributions " given a lot of success OpenBSD has had in the past several years dodging exploits that resulted from bug-present distribution issues, that its OS compartmentalization approach has successfully avoided.

nickpsecurity 10y ago

You just argued that OpenBSD is more secure because it has specific feature set. You didnt prove these are the right combo of features, that they in solo/combo work against strong attackers (instead of obscurity advantage), or even strongest ones of their respective classes (they're not). You started with OpenBSD's features, accepted the claims as fact, ignored all other tech/requirements, and then asked other party to prove their claim with evidence. Wrong way to do an argument for or even against OpenBSD. You need to establish requirements for security in many areas, features/practices to support those, assurance they work, and then what each OS or system possesses. OpenBSD has only partly done this so I doubt uou have. I look forward to you posting that analysis for OpenBSD and its preferred hardware.

notaplumber 10y ago
> You didnt prove these are the right combo of features, that they in solo/combo work against strong attackers (instead of obscurity advantage), or even strongest ones of their respective classes (they're not) Security mitigations work best in combinations, the entire purpose is to make it as hard as possible to attack the system.. suggesting OpenBSD's mitigations aren't the strongest in their class clearly needs some proof on your part, but I don't expect you'll deliver. > You started with OpenBSD's features, accepted the claims as fact. I stated the facts, because I'm aware of and closely followed their development, having tested them. I accepted no claims as "facts". You can easily verify everything I've said, OpenBSD is open source.. and shocking, they pioneered that too.. having created anoncvs. Not much left to reply to in your post, because you're just grasping at proverbial straws.
- nickpsecurity 10y ago
  "Security mitigation work best in combinations," Exactly the kind of meaningless statement I was talking about. You've neither proven they work in isolation nor shown they're a strong combination against determined attackers. Almost all of those people are hitting Windows, Linux, iOS, and Android due to market share. Im not sure we've even seen thorough test of OpenBSD's defenses. "suggesting OpenBSD's mitigations aren't the strongest in their class clearly needs some proof on your part" Let's try a few memory or stack issues. SPARK can prove the absence of most of them. Concurrent Pascal and Eiffel could for concurrency. Rust can for dynamic memory and concurrency. SAFEcode does for many C-related errors. Example uses are in Muen, Redox, and SVA-OS. Softbound + CETS goes further with total spatial and temporal safety for C but not in OS's yet. These are all stronger than OpenBSD techniques for similar use cases. Different tradeoffs involved in using them but definitely stronger. I mean, full safety without GC is strongest you can get in memory errors. Although SPIN OS did it in Modula-3 with GC and type-safe linking too. "and shocking, they pioneered that too.. having created anoncvs." Your lack of research is apparent as the first, secure OS with source was Burroughs B5000. It was proprietary but shipped source. Had stack checks, bounds checking, pointer protection, OS in high-level language, compile-time checks for function calls, and run-time checks for invalid arguments. Started high-assurance security by addressing root causes of most known issues... in 1961. It's also not easy to figure out OpenBSD security effectiveness looking at source. The safer languages like Modula-3 or techniques of B5000/JX-OS/Genode are easy to follow since they are simple & fully preventative. Verify that then the rest inherits its properties if used or interfaced certain way. Not so with OpenBSD's scattered mechanisms: requires much more analysis given use of C and stuff in kernel mode. Finally, bringing up AnonCVS, you might want to look at David Wheeler's Software Configuration Management security page to see what high-security requires in that. Shapiro's OpenCM (in architecture) or competing Aegis (features) were ahead in many ways with OpenBSD's SCM tactics not registering a blip due to missing requirements on Wheeler et al's lists. I even watched them replaced a distribution tool known to resist NSA per Snowden leaks for a simpler, but unproven, one. OpenBSD has proven great at configuration, code quality, and minimalism. Burden of proof is still on it in terms of security engineering practices vs other methods or OS's. It's never been proven from requirements to methods to results. Fine with me as it has it's uses, esp where 0-days being low is top priority. Best not to pretend it is something it's not vs making the case with evidence as I described.

ryuuchin 10y ago

Linux with grsecurity is a pretty obvious alternative. There are distros which include grsecurity patched kernels in their repo (or use it by default) although going this route over a self-compiled one does loose out on a few security features. Some grsecurity features are supersets of the features you listed such as the W^X protections (which I might add have been in PaX for quite some time now). While the situation certainly isn't perfect with getting more packages using PIE at least a number of important packages are now built with that by default. Arch Linux compiles all packages in its repo's with stack protection AFAIK and at least on Arch it's very easy to recompile things to suit your (performance) needs/threat model. Perhaps OpenBSD offers more of these compiled protections by default in its base/ports but you can still get these options on Linux if you're willing to put a little effort in or use the right distro for your needs. OpenBSD is less of an obvious choice when you look at what you can do with grsecurity if you put a bit of effort into it both on the side of grsecurity (RBAC) and setting up your distro. You can't just wave your hand and dismiss grsecurity because you believe it to be non-standard/non-upstream or somehow incomprehensible/complicated. It's not about what's enabled by default, it's about how much security/protection/defense in depth I can get from it and arguably you get more from Linux w/grsecurity.

ben_bai 10y ago
The point is "optional security is bad security" because when stuff doesn't work it gets turned off. So _nobody_ turns those things on. In OpenBSD all the mitigations are enabled all the time, and with pledge beeing the responsibility of the coder, no extra effort needed from the sys admin.
- ryuuchin 10y ago
  I was just trying to make a point that OpenBSD is not always the best choice for all possible use cases to expand upon tptacek's post a little. In may be for someone uninformed or lazy but my argument is if you're willing to put in a little effort you can get a system which is arguably better from a security and defense in depth standpoint than OpenBSD. There are obvious benefits to both but I don't think that grsecurity is something which can be dismissed as easily as saying nobody uses it.

danieldk 10y ago

Red Hat Enterprise Linux (and thus CentOS) has many of those features: https://access.redhat.com/articles/65299 https://access.redhat.com/articles/65299 Also, it provides MAC per SELinux.

eugeneionesco 10y ago

>What other system has enabled by default the following security mitigations Let's see. >Enforced W^X in the kernel Linux, OS X, Windows >Enforced W^X userland as of 6.0 Linux >Stack protector (..which OpenBSD pushed into wide adoption). Literally every other OS out there has stack protector, and it was Windows pushing it to wide adoption >PIE by default for base and ports. Linux >Static-PIE for self-relocating static binaries. Linux >SROP (sigreturn(2) oriented programming) mitigation by default. Useless "mitigation", can be easily bypassed with no effort >C shared library re-ordering at boot time, i.e: libc.so is re-linked at boot time so objects are randomly ordered. Useless mitigation, can be easily bypassed with no effort >System-wide sandboxing (pledge(2)) of a large percentage of the userland Large percentage? I disagree, it's more like 10%.

marios 10y ago
The key word is "by default". I have no idea whether the Linux kernel that each distro ships enforced W^X. For userland, the effort is undergoing. For instance, I recently packaged a C application for Debian. Then, by sheer luck I stumbled upon the Debian Wiki[0] where it explained that one needs to specify "DEB_BUILD_MAINT_OPTIONS = hardening=+all" to enable compiler hardening options. Why isn't that on by default ? The wiki asks the reader to enable hardening if the program handles untrusted data. Doesn't that apply to 99% of the applications out there ? Even it only reads its own configuration file, there is a possibility of a bug in the parser. Why take the risk at all ? Enable it by default for everyone and be done with it. Regarding the pledge(2) sandboxing, pretty much every userland application in the base install of OpenBSD where is makes sense to sandbox is using pledge. Ports/packages are another story entirely. [0] https://wiki.debian.org/Hardening#Using_Hardening_Options https://wiki.debian.org/Hardening#Using_Hardening_Options
- ryuuchin 10y ago
  Arch Linux enables -fstack-protector-strong last I checked by default. I admit Debian often drags it feet on some things like this but I think Ubuntu has enabled it for a number of packages as well.

nwmcsween 10y ago

iirc openbsd uses fno-strict-aliasing in the base system because the code is buggy.

cm3 10y ago

> What other system has enabled by default the following security mitigations HardenedBSD already ticks off most points and is actively working on the rest.