10 ms·

The Insecurity of OpenBSD (2010)

66 points by rev 10y ago

tptacek 10y ago
OpenBSD by itself contains a feature set similar in comparison to the GRSecurity patch for Linux without the ACL or RBAC implementation. GRSecurity and the Openwall project actually pioneered many of the protections that occurred later in OpenBSD such as Executable Space Protection, chroot restrictions, PID randomization and attempts to prevent race conditions On the one hand: I think OpenBSD did pioneer some of these things (PID randomization --- randomization of all monotonically increasing IDs, really --- was something TdR was doing in the 1990s). Privsep daemons might be another example. On the other hand, I'm not sure I buy that OpenBSD has a feature set comparable to GRsecurity without the ACL/RBAC stuff.
- JoachimSchipper 10y ago
  GrSecurity has more kernel-level protection features, I think. If I wanted to argue that OpenBSD is more secure than e.g. Ubuntu with GrSecurity, I'd focus on OpenBSD's hardening/security-conscious design throughout the system. (ETA:) GrSecurity gives you great anti-exploit technology, but having fewer total bugs also helps. (E.g. OpenBSD has beautiful code, most of the base system pledge'd, ASLR/stack overflow protection/W^X/prices/auditing everywhere, doesn't stuff tons of complexity into everything, ...)
- milcron 10y ago
  Just to try and explain where I feel the OpenBSD project is coming from... their philosophy is a little different. At the very beginning OpenBSD was not about security per se, but about simplicity of implementation and stark, clean code. It turns out this results in a rather secure system (go figure). It was only after the fork from NetBSD that OpenBSD gained a real security orientation... I think there was some client who wanted a secure OS, and they helped fund the audit of OpenBSD's codebase. Yet even today OpenBSD's philosophy is better explained as a focus on stark simplicity. Coming from that perspective, many of their decisions make sense. ACLs are a terribly complex mechanism that would require a lot of new code added to the kernel. Any new code is a deadweight that needs to be tested, audited, maintained, etc. across a large number of platforms, not just x86 and ARM. OpenBSD (historically) has no hypervisor for the same reason. It's an incredibly complicated feature that would be difficult to implement securely and succinctly. As Theo put it (in characteristically brusque style): >x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. >You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. That said, OpenBSD has pioneered a lot of security features. They created sudo in 1997, recently replaced sudo with a simpler program `doas`. OpenBSD was the first mainstream OS to have ASLR turned on by default. And their new privilege-drop feature `pledge` looks great. In the end, they're a smaller project with less manpower so it's impressive they achieve what they do. Obviously auditing the entire ports tree is going to be out of scope... auditing Firefox alone would probably be a multi-million dollar project.
  - tptacek 10y ago
    Yeah, I was there at the beginning of the OpenBSD audit (there, as in, in Canada, at times in Theo's basement), and for a few years was the person writing the advisories (I'm particularly proud of rfork and the I/O signal advisory). I don't dispute that OpenBSD is good at the small-bore Unix stuff. They are! I think OpenBSD is the undisputed master of small-bore Unix security. If you want something in userland priv-separated or some ID randomized, call the OpenBSD team. The problem though is exactly what this article says it is: the code OpenBSD has custody over is a small fraction of the code users need to run, and OpenBSD's code just isn't up to the challenge of securing other people's code. Modern Linux security has taken the other road: part of the kernel's job is --- at least in GRsecurity-world --- to assume that you're running insecure C code, and still not lose your kernel to an attacker's persistence tools.
    - milcron 10y ago
      Did not mean to preach to the choir, hah! I would argue that pledge goes a long way towards addressing the problems of insecure C code, although it's definitely not as fine-grained as ACLs.
  - jlgaddis 10y ago
    You do know that OpenBSD just recently introduced a hypervisor, right? (From the "(historically)", I'm guessing you do but others reading this may not realize that OpenBSD now does ship with a hypervisor. It's very "early", though, FWIW.)
    - milcron 10y ago
      Correct. Currently it can only run OpenBSD guests, and it only supports x86. The landscape is a little different now that hypervisors are no longer cutting edge, and the x86 architecture has improved virtualization abilities which help prevent some security flaws.
      - dom0 10y ago
        Wasn't TdR statement before hardware virtualization on x86 became commonplace? Before AMD-V / Intel VT x86 virtualization worked through bizarrely complex techniques (binary translation...)
hhw 10y ago
There are two different schools of thought to a secure operating system. One is to add features / layers to enhance security, such as with GRSecurity. The other is to ensure correctness, so that there are no bugs to exploit. OpenBSD takes the latter approach, as they're of the opinion that additional features and layers result in more complexity with increased probability of bugs and/or misuse. Also, it's a misconception that OpenBSD's primary focus is security; the primary focus is in fact on correctness, with security being an important but auxiliary benefit of that. The article posted makes the argument that the first approach is the only true approach to a secure operating system, and that OpenBSD is thus insecure by definition. There's not enough data / samples of secure operating systems to make an intellectually honest assertion that one approach is definitively superior, but OpenBSD likely has the best security track record for an operating system in real-world scenarios. point of reference: years of following the OpenBSD mailing lists
- vbezhenar 10y ago
  pledge, W^X are examples of the former approach.
- danieldk 10y ago
  There's not enough data / samples of secure operating systems to make an intellectually honest assertion that one approach is definitively superior, but OpenBSD likely has the best security track record for an operating system in real-world scenarios. While auditing is definitely a good idea, the latter approach only works when you only run services and applications that are part of OpenBSD. Since that is not the case for most realistic usage scenarios, OpenBSD gives you very little, while the former approach (think e.g. SELinux) can help you with isolating applications that you trust, but not as much as, say OpenBSD.
  - upofadown 10y ago
    The comment you are replying to does not mention auditing.
    - ljw_dev 10y ago
HugoDaniel 10y ago
Aren't all of these solved by pledge ? Also his counter-argument on secure-levels is not convincing. "Securelevels are an interesting concepts and they do help with security somewhat. Securelevels can only be increased not decreased on a running system. The higher levels prevent writing to /dev/mem and /dev/kmem, removing file immutable flags, loading kernel modules and changing pf rules. These all help to restrict what an attacker can do, but do absolutely nothing to prevent reading or changing database records, obtaining user info, running malicious programs etc." Securelevels are what they are, and should be used accordingly. This is just bad judgement of the technology. Please don't assume something does more than what it actually does, this is not a good practice, please read the documentation and/or talk with the community, securelevels are well documented. It is very bad to expect securelevels to protect your database from being changed or your code from being abused and use that as an argument against the OS. (edited, small typos: added an "it" and changed SO to OS)
- dispose13432 10y ago
  pledge and, say, SELinux solve two different problems: Pledge stops trusted software from being exploited. I trust Apache (I run it as root) but the authors can't guarantee that it can't get exploited, so it's protected by pledge. If I didn't trust Apache, I wouldn't trust that it pledged anything. SELinux secures un-trusted code. So if I download a program off the internet and run it as nobody, it shouldn't exploit something to get root. This is useful when downloading random closed-source programs (such as on Android). Unfortunately, Linux relies on SELinux to solve problem #1 (how do I know which files does Apache really need, and which won't help security exploits), which is why it gets such a terrible reputation.
  - djsumdog 10y ago
    I've had to make AppArmor profiles in the past and they can get a bit painful. I've never had to configure SELinux so I don't know how much better/worse it is. That being said, I think Docker and other container systems are going to remove the need for these security profile systems. Yes, if there is exploitable code in the container, it can read/write to other things in the container. But so long as you keep the docker daemon up to date on its security patches, application exploits shouldn't be able to leak beyond the container, with the exception of volumes and linked containers/ports.
bandrami 10y ago
Ah, the age old promise of MACs: perfectly secure, as long as you don't think very hard about the fact that somebody has to administer the access control rules.
- danieldk 10y ago
  MACs come in many different flavors. E.g. AppArmor is very easy to administrate an provides security over running 'random' applications without MAC.
  - bandrami 10y ago
    There's two separate issues here, both of which apply: 1. A knob that can't be configured can't be misconfigured (IIRC Debian had a hole in its default selinux config for years that created a vulnerability selinux-less machines didn't have) 2. (This was more what I meant) the promise that makes people like MACs is that you no longer need a single all-powerful root user to do everything (this bleeds into ACLs and capabilities, too), but keeps running into two icebergs: 2a. Somebody still has to administer those controls, and so can effectively become that all-powerful root, and 2b. The only stuff I actually care about is the actual data that the application being sandboxed can access to begin with. This gives us the particularly pointless exercise in which somebody who steals my laptop can impersonate me on gmail and social media, empty my bank account, and delete all my github repos, but can't change the laptop's time zone. The system files that I can download for free at any time are protected, but the manuscript for my novel is not.
    - dom0 10y ago
      > capabilities Well. There just aren't many useful caps to begin with. For example, consider backups. You'd want the backup system to have full read access to everything. Well. You can't do that with capabilities. You only get DAC_OVERRIDE, which is one of the many root-equivalent caps in Linux. Probably half of them are.
      - ori_b 10y ago
countingteeth 10y ago
Much to like, but one point is somewhat outdated and another is missing. 1. The lack of an AppArmor-type MAC implementation is somewhat outdated since Theo rolled his own with "pledge". I'm not a huge fan of how a cabal of Theo plus one or two guys basically hacks out something of new cloth on a whim to solve a problem that's been done many times before, on the arrogant supposition they're doing it better than anyone else has ever done, and then promptly stuck it into production. This has happened many times before. Certainly some results have been good, but case in point, "doas". You upgrade one point release and suddenly sudo is not there any more, you have a new tool lacking basic features with completely different semantics. Yes, you can install sudo as a package if you want. Yes, maybe doas is smaller and easier to audit. But was sudo really a problem? Sure the fanboys will love it, but most normal UNIX people are probably not going to appreciate something like sudo just going away. It lacks little "features" like credential caching, which I am sure the fanboys will tell you is bad to begin with, but which most of the rest of us will find a pain in the ass. This sort of thing happens with OpenBSD semiregularly. Of course, many of these homegrown solutions are produced after years of Theo & cabal insisting that there was no need for it and it was wrongheaded. There's "pledge," but then there's little things like full-disk encryption, which is basically a requirement for use on mobile, but which OpenBSD never had any use for, until it did, and came out with its own homegrown thing (which still doesn't work that great, especially when upgrading). *And since so many others have brought up pledge, it's not really a solution on the same scale since you have to build the pledges into the application, there's not an easy system for imposing pledges on an application externally. This makes maintenance and adoption much harder, basically nonexistent for most of the package tree. 2. The big reason OpenBSD is insecure, is its lack of any meaningful update mechanism to their supposedly rock-solid secure base system. Literally the official way to do security updates is to monitor OpenBSD's website, download and apply patches by hand to a source install, rebuild, and run a series of listed commands by hand. If you want to automate this further, you are on your own. It's been this way forever. It's craziness, and it a big reason that OpenBSD is basically not an option for production in many settings. Upgrading to new releases is a similar deal. The homegrown sysmerge hack has made this slightly less awful, but manual hackery is still required, unreliable, can wipe out customization, and doing a clean reinstall is still urged as the best path in many cases.
- 10y ago
youdontknowtho 10y ago
This guys makes some good points, but the OpenBSD guys have been able to improve the security of OBSD with code quality. It's also not completely accurate to say that OpenBSD hasn't contributed anything to security. They have. Maybe it was more true in 2010, but it's certainly not the case now. I have found lots of Unix people (devs and admins) don't really seem to care much for MAC. I don't really understand it, but its true.
- ams6110 10y ago
  Admins in particular like to (a) understand how things are configured and (b) avoid changing things (creates work and potential update conflicts). MAC configuration is complicated, tedious, error prone, and seems to bite you in the ass with every update. All things that make a bad day for an admin.
  - youdontknowtho 10y ago
    I'm an admin. Have been for many, many, moons. I've found that when things seen to behave that way it's because I have failed to sufficiently adjust my understanding of them. Often, we can be guilty of expecting that everything should behave like the least common denominator set of features between all host systems. Often, there is great value in finding "the way" that a particular system is trying to exemplify instead of forcing it to match my own. To be fair, that least common denominator set of features can be very powerful and capable. It's not a slam, I'm just saying that finding out the in depth method of operation for a given system can often be rewarding.
- deleted 10y ago
  [deleted]
countingteeth 10y ago
Ya'll are beyond parody. It was added to CVS two months ago? Yay. I'll be sure to upgrade and rebuild from dev in CVS. Call me when doas has finished reimplementing sudo, oh so much better and more auditably.
- notaplumber 10y ago
  It's was never intended to completely replace sudo, but now you're just pulling teeth.
  - countingteeth 10y ago
    It wasn't? Then why did they? As I've repeatedly reminded, sudo is in ports. I thought credential caching was left out because it was another unnecessary bloated feature creep and doas is supposed to be minimal and more secure. Apparently people couldn't live without it, and it's added in three releases later.
    - notaplumber 10y ago
      If you followed development, sudo in OpenBSD was maintained by Todd C. Miller, the same person who maintains the sudo.ws version. The version in OpenBSD was years behind and had many features stripped out or disabled. It was a maintenance burden and people wanted the upstream version in ports to get features like plugins, LDAP, etc.
- sctb 10y ago
  We detached this flagged subthread from https://news.ycombinator.com/item?id=13065270 https://news.ycombinator.com/item?id=13065270.
elchief 10y ago
Ports might be unaudited, but OpenBSD base has lots of useful stuff that many people don't know about. Like OpenBSD's own web server, LDAP server, IPSEC/VPN implementation, time server ... All priv-sep'd, simplified, pledged Also, these days the preferred MTA is OpenSMTP, and the preferred name server is NSD
atmosx 10y ago
Out of curiosity, anyone ever worked with an hardened OpenBSD or Linux + GRSec server farm? How do you handle updates? It must a sysadmin deployment nightmare.
- micaksica 10y ago
  It's not that bad once you have it set up. PaX causes most issues. You run a custom repo with two packages, your compiled linux-grsec kernel, and a package that contains paxd and paxd exceptions for your typical binaries. Once you find a stable grsecurity kernel config you don't really have much to worry about. When new updates are released, test them on your test tier with your existing PaX rules and exemptions, and if they pass tests push them into prod. Worst case scenario you disable PaX (and its memory protections) in emergency cases or rollback to the known good version. If you are running "unattended-upgrades" or something else and letting your tiers autopatch themselves, well, that's dangerous to stability in and of itself. I run -grsec-patched kernels on all of my personal workstations as well. That's when grsec can be a pain.
- Gracana 10y ago
  I do manual upgrades on my machines because I only have a few and they're different enough that automation wouldn't help, buuuut... You can use release(8) and autoinstall(8) with pxe to deploy create and deploy OpenBSD upgrades/installs. In between releases, you can follow the -stable branch of the ports tree and use dpb(1) to generate updated binary packages, which all your machines can then install.
- milcron 10y ago
  I don't operate a server farm but OpenBSD updates are pretty easy. Just do `pkg_add -Uu`. If your dependencies are minimal, keeping OpenBSD up-to-date is actually pretty relaxing. Don't need to install security patches all the time as with Linux.
  - countingteeth 10y ago
    pkg_add -Uu won't address a single update under https://www.openbsd.org/errata.html https://www.openbsd.org/errata.html , i.e. the very most important ones. Also as far as I know pkg_add still doesn't know about restarting services, so vulnerable processes will be left running.
gbrown_ 10y ago
I would simply say OpenBSD runs. It runs with it's hardening mechanisms always on. Ports are considered in whether a new mechanism or aggressiveness of an existing mechanism is suitable. The idea is to have a platform where good quality software runs and bad quality software crashes. See the evolution of the default malloc.conf options or more recently the explicit enforcement of W^X. It's true OpenBSD was not founded with the intention of being "the secure OS" but the ethos of designing secure software is very much something that is core to the developers today. Others have already pointed out cons as well as pros of MAC style systems which this post laments the lack of in OpenBSD. I'll simply say I prefer the approach of pledge. Yes you need to build it into the application but I think that kind of upfront explicitness is better than a policy system and I hope other platforms adopt it.
wyager 10y ago
> There is no good reason to avoid implementing extended access controls when the greater security and control they provide is irrefutable. Disagreed. MAC is a crutch and a hack, not a solution. We should prefer not to rely on half-assed, overcomplicated, and formally unverifiable palliative measures. If you want security, you fundamentally must use secure software. No amount of sandboxing or access control wrapped around a vulnerable garbage heap is going to stop the garbage heap from getting hacked in the first place.
- nickpsecurity 10y ago
  There were numerous examples of MAC, esp SELinux, stopping vulnerabilities. There's also plenty of examples of bugs and vulnerabilities in software with OpenBSD even fixing bugs regularly. The claim that one should reduce bugs and have damage limitation to reduce overall risk is rock solid with proof in the field. The refrain of OpenBSD supporters is, "It's not necessary and won't help..." The reality in field deployments, "It was and did." QED.
  - wyager 10y ago
    > There's also plenty of examples of bugs and vulnerabilities in software with OpenBSD even fixing bugs regularly. As the OpenBSD devs will tell you, there have only been two known vulnerabilities in default OpenBSD installs in the history of OpenBSD. This strongly suggests that having decent software quality is an effective way to prevent vulnerabilities from existing in the first place. > The refrain of OpenBSD supporters is, "It's not necessary and won't help..." No, the refrain is "it's better to spend effort curing the disease than treating the symptoms". If we put half the effort we put into palliative defense measures into formal verification or doing things right the first time, I suspect it would be drastically more effective.
    - nickpsecurity 10y ago
      "As the OpenBSD devs will tell you, there have only been two known vulnerabilities in default OpenBSD installs in the history of OpenBSD. This strongly suggests that having decent software quality is an effective way to prevent vulnerabilities from existing in the first place." I addressed that myth in my main comment. See here: http://pastebin.com/6cW3FyJE http://pastebin.com/6cW3FyJE They just assess and count differently than most folks. ;) " If we put half the effort we put into palliative defense measures into formal verification or doing things right the first time, I suspect it would be drastically more effective." I agree being on side of high-assurance security. OpenBSD doesn't so I don't know your statement supports what they do. They systematically avoid formal verification like what you described, safer languages, coding styles for static analysis, etc. It's people from my side of things promoting or building on those. They just hunt bugs in C code by eye and hope their probabilistic mitigations always work. Totally different.
deleted 10y ago
[deleted]
module0000 10y ago
What mission critical systems is OpenBSD running anywhere? I'm talking about the OS itself, not one of the pieces of software developed as part of the project and ported to other platforms(eg openssh). Not trolling, but genuinely curious where OpenBSD is running outside of our basements.
- milcron 10y ago
  Users don't have to reveal themselves, but there's a list available at https://www.openbsd.org/users.html https://www.openbsd.org/users.html I see lots of academies, ISPs, and even Adobe is in there,
- nickpsecurity 10y ago
  Genua on milcron's list is probably most significant. They are a defense contractor that sells firewalls, VPN's, data diodes, etc for business and government (including military). You can bet significant applications are protected with them. This is the kind of role most of its users put it in. Others just use it like any other server OS with better reputation for reliability and security. Less patching... a time-consuming activity... at the least. Last one was similar reason for adoption of Argus Pitbull and SELinux w/ Tresys tools in their niches. Less worries when malware is going viral on the Internet and in media. ;)
nickpsecurity 10y ago
Interesting for this post to turn up as I was drafting and getting review for my own rebuttal to OpenBSD propaganda on Schneier's forum. I couldn't find it as I needed it. (shrugs) Quick attempt at redoing it here. Started with this on Lobste.rs forum that's popular for OpenBSD developers: https://home.nuug.no/~peter/blug2016/img1.html https://home.nuug.no/~peter/blug2016/img1.html Similar to some of the BS allthatiswrong counters. I'm just focusing on a few as it will already be a long writeup with many examples from history on where secure coding and UNIX really came from. In this Pastebin: http://pastebin.com/6cW3FyJE http://pastebin.com/6cW3FyJE

66 points by rev 10y ago

OpenBSD by itself contains a feature set similar in comparison to the GRSecurity patch for Linux without the ACL or RBAC implementation. GRSecurity and the Openwall project actually pioneered many of the protections that occurred later in OpenBSD such as Executable Space Protection, chroot restrictions, PID randomization and attempts to prevent race conditions On the one hand: I think OpenBSD did pioneer some of these things (PID randomization --- randomization of all monotonically increasing IDs, really --- was something TdR was doing in the 1990s). Privsep daemons might be another example. On the other hand, I'm not sure I buy that OpenBSD has a feature set comparable to GRsecurity without the ACL/RBAC stuff.

JoachimSchipper 10y ago
GrSecurity has more kernel-level protection features, I think. If I wanted to argue that OpenBSD is more secure than e.g. Ubuntu with GrSecurity, I'd focus on OpenBSD's hardening/security-conscious design throughout the system. (ETA:) GrSecurity gives you great anti-exploit technology, but having fewer total bugs also helps. (E.g. OpenBSD has beautiful code, most of the base system pledge'd, ASLR/stack overflow protection/W^X/prices/auditing everywhere, doesn't stuff tons of complexity into everything, ...)
milcron 10y ago
Just to try and explain where I feel the OpenBSD project is coming from... their philosophy is a little different. At the very beginning OpenBSD was not about security per se, but about simplicity of implementation and stark, clean code. It turns out this results in a rather secure system (go figure). It was only after the fork from NetBSD that OpenBSD gained a real security orientation... I think there was some client who wanted a secure OS, and they helped fund the audit of OpenBSD's codebase. Yet even today OpenBSD's philosophy is better explained as a focus on stark simplicity. Coming from that perspective, many of their decisions make sense. ACLs are a terribly complex mechanism that would require a lot of new code added to the kernel. Any new code is a deadweight that needs to be tested, audited, maintained, etc. across a large number of platforms, not just x86 and ARM. OpenBSD (historically) has no hypervisor for the same reason. It's an incredibly complicated feature that would be difficult to implement securely and succinctly. As Theo put it (in characteristically brusque style): >x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. >You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. That said, OpenBSD has pioneered a lot of security features. They created sudo in 1997, recently replaced sudo with a simpler program `doas`. OpenBSD was the first mainstream OS to have ASLR turned on by default. And their new privilege-drop feature `pledge` looks great. In the end, they're a smaller project with less manpower so it's impressive they achieve what they do. Obviously auditing the entire ports tree is going to be out of scope... auditing Firefox alone would probably be a multi-million dollar project.
- tptacek 10y ago
  Yeah, I was there at the beginning of the OpenBSD audit (there, as in, in Canada, at times in Theo's basement), and for a few years was the person writing the advisories (I'm particularly proud of rfork and the I/O signal advisory). I don't dispute that OpenBSD is good at the small-bore Unix stuff. They are! I think OpenBSD is the undisputed master of small-bore Unix security. If you want something in userland priv-separated or some ID randomized, call the OpenBSD team. The problem though is exactly what this article says it is: the code OpenBSD has custody over is a small fraction of the code users need to run, and OpenBSD's code just isn't up to the challenge of securing other people's code. Modern Linux security has taken the other road: part of the kernel's job is --- at least in GRsecurity-world --- to assume that you're running insecure C code, and still not lose your kernel to an attacker's persistence tools.
  - milcron 10y ago
    Did not mean to preach to the choir, hah! I would argue that pledge goes a long way towards addressing the problems of insecure C code, although it's definitely not as fine-grained as ACLs.
- jlgaddis 10y ago
  You do know that OpenBSD just recently introduced a hypervisor, right? (From the "(historically)", I'm guessing you do but others reading this may not realize that OpenBSD now does ship with a hypervisor. It's very "early", though, FWIW.)
  - milcron 10y ago
    Correct. Currently it can only run OpenBSD guests, and it only supports x86. The landscape is a little different now that hypervisors are no longer cutting edge, and the x86 architecture has improved virtualization abilities which help prevent some security flaws.
    - dom0 10y ago
      Wasn't TdR statement before hardware virtualization on x86 became commonplace? Before AMD-V / Intel VT x86 virtualization worked through bizarrely complex techniques (binary translation...)

hhw 10y ago

There are two different schools of thought to a secure operating system. One is to add features / layers to enhance security, such as with GRSecurity. The other is to ensure correctness, so that there are no bugs to exploit. OpenBSD takes the latter approach, as they're of the opinion that additional features and layers result in more complexity with increased probability of bugs and/or misuse. Also, it's a misconception that OpenBSD's primary focus is security; the primary focus is in fact on correctness, with security being an important but auxiliary benefit of that. The article posted makes the argument that the first approach is the only true approach to a secure operating system, and that OpenBSD is thus insecure by definition. There's not enough data / samples of secure operating systems to make an intellectually honest assertion that one approach is definitively superior, but OpenBSD likely has the best security track record for an operating system in real-world scenarios. point of reference: years of following the OpenBSD mailing lists

vbezhenar 10y ago
pledge, W^X are examples of the former approach.
danieldk 10y ago
There's not enough data / samples of secure operating systems to make an intellectually honest assertion that one approach is definitively superior, but OpenBSD likely has the best security track record for an operating system in real-world scenarios. While auditing is definitely a good idea, the latter approach only works when you only run services and applications that are part of OpenBSD. Since that is not the case for most realistic usage scenarios, OpenBSD gives you very little, while the former approach (think e.g. SELinux) can help you with isolating applications that you trust, but not as much as, say OpenBSD.
- upofadown 10y ago
  The comment you are replying to does not mention auditing.
  - ljw_dev 10y ago

HugoDaniel 10y ago

Aren't all of these solved by pledge ? Also his counter-argument on secure-levels is not convincing. "Securelevels are an interesting concepts and they do help with security somewhat. Securelevels can only be increased not decreased on a running system. The higher levels prevent writing to /dev/mem and /dev/kmem, removing file immutable flags, loading kernel modules and changing pf rules. These all help to restrict what an attacker can do, but do absolutely nothing to prevent reading or changing database records, obtaining user info, running malicious programs etc." Securelevels are what they are, and should be used accordingly. This is just bad judgement of the technology. Please don't assume something does more than what it actually does, this is not a good practice, please read the documentation and/or talk with the community, securelevels are well documented. It is very bad to expect securelevels to protect your database from being changed or your code from being abused and use that as an argument against the OS. (edited, small typos: added an "it" and changed SO to OS)

dispose13432 10y ago
pledge and, say, SELinux solve two different problems: Pledge stops trusted software from being exploited. I trust Apache (I run it as root) but the authors can't guarantee that it can't get exploited, so it's protected by pledge. If I didn't trust Apache, I wouldn't trust that it pledged anything. SELinux secures un-trusted code. So if I download a program off the internet and run it as nobody, it shouldn't exploit something to get root. This is useful when downloading random closed-source programs (such as on Android). Unfortunately, Linux relies on SELinux to solve problem #1 (how do I know which files does Apache really need, and which won't help security exploits), which is why it gets such a terrible reputation.
- djsumdog 10y ago
  I've had to make AppArmor profiles in the past and they can get a bit painful. I've never had to configure SELinux so I don't know how much better/worse it is. That being said, I think Docker and other container systems are going to remove the need for these security profile systems. Yes, if there is exploitable code in the container, it can read/write to other things in the container. But so long as you keep the docker daemon up to date on its security patches, application exploits shouldn't be able to leak beyond the container, with the exception of volumes and linked containers/ports.

bandrami 10y ago

Ah, the age old promise of MACs: perfectly secure, as long as you don't think very hard about the fact that somebody has to administer the access control rules.

danieldk 10y ago
MACs come in many different flavors. E.g. AppArmor is very easy to administrate an provides security over running 'random' applications without MAC.
- bandrami 10y ago
  There's two separate issues here, both of which apply: 1. A knob that can't be configured can't be misconfigured (IIRC Debian had a hole in its default selinux config for years that created a vulnerability selinux-less machines didn't have) 2. (This was more what I meant) the promise that makes people like MACs is that you no longer need a single all-powerful root user to do everything (this bleeds into ACLs and capabilities, too), but keeps running into two icebergs: 2a. Somebody still has to administer those controls, and so can effectively become that all-powerful root, and 2b. The only stuff I actually care about is the actual data that the application being sandboxed can access to begin with. This gives us the particularly pointless exercise in which somebody who steals my laptop can impersonate me on gmail and social media, empty my bank account, and delete all my github repos, but can't change the laptop's time zone. The system files that I can download for free at any time are protected, but the manuscript for my novel is not.
  - dom0 10y ago
    > capabilities Well. There just aren't many useful caps to begin with. For example, consider backups. You'd want the backup system to have full read access to everything. Well. You can't do that with capabilities. You only get DAC_OVERRIDE, which is one of the many root-equivalent caps in Linux. Probably half of them are.
    - ori_b 10y ago

countingteeth 10y ago

Much to like, but one point is somewhat outdated and another is missing. 1. The lack of an AppArmor-type MAC implementation is somewhat outdated since Theo rolled his own with "pledge". I'm not a huge fan of how a cabal of Theo plus one or two guys basically hacks out something of new cloth on a whim to solve a problem that's been done many times before, on the arrogant supposition they're doing it better than anyone else has ever done, and then promptly stuck it into production. This has happened many times before. Certainly some results have been good, but case in point, "doas". You upgrade one point release and suddenly sudo is not there any more, you have a new tool lacking basic features with completely different semantics. Yes, you can install sudo as a package if you want. Yes, maybe doas is smaller and easier to audit. But was sudo really a problem? Sure the fanboys will love it, but most normal UNIX people are probably not going to appreciate something like sudo just going away. It lacks little "features" like credential caching, which I am sure the fanboys will tell you is bad to begin with, but which most of the rest of us will find a pain in the ass. This sort of thing happens with OpenBSD semiregularly. Of course, many of these homegrown solutions are produced after years of Theo & cabal insisting that there was no need for it and it was wrongheaded. There's "pledge," but then there's little things like full-disk encryption, which is basically a requirement for use on mobile, but which OpenBSD never had any use for, until it did, and came out with its own homegrown thing (which still doesn't work that great, especially when upgrading). *And since so many others have brought up pledge, it's not really a solution on the same scale since you have to build the pledges into the application, there's not an easy system for imposing pledges on an application externally. This makes maintenance and adoption much harder, basically nonexistent for most of the package tree. 2. The big reason OpenBSD is insecure, is its lack of any meaningful update mechanism to their supposedly rock-solid secure base system. Literally the official way to do security updates is to monitor OpenBSD's website, download and apply patches by hand to a source install, rebuild, and run a series of listed commands by hand. If you want to automate this further, you are on your own. It's been this way forever. It's craziness, and it a big reason that OpenBSD is basically not an option for production in many settings. Upgrading to new releases is a similar deal. The homegrown sysmerge hack has made this slightly less awful, but manual hackery is still required, unreliable, can wipe out customization, and doing a clean reinstall is still urged as the best path in many cases.

10y ago

youdontknowtho 10y ago

This guys makes some good points, but the OpenBSD guys have been able to improve the security of OBSD with code quality. It's also not completely accurate to say that OpenBSD hasn't contributed anything to security. They have. Maybe it was more true in 2010, but it's certainly not the case now. I have found lots of Unix people (devs and admins) don't really seem to care much for MAC. I don't really understand it, but its true.

ams6110 10y ago
Admins in particular like to (a) understand how things are configured and (b) avoid changing things (creates work and potential update conflicts). MAC configuration is complicated, tedious, error prone, and seems to bite you in the ass with every update. All things that make a bad day for an admin.
- youdontknowtho 10y ago
  I'm an admin. Have been for many, many, moons. I've found that when things seen to behave that way it's because I have failed to sufficiently adjust my understanding of them. Often, we can be guilty of expecting that everything should behave like the least common denominator set of features between all host systems. Often, there is great value in finding "the way" that a particular system is trying to exemplify instead of forcing it to match my own. To be fair, that least common denominator set of features can be very powerful and capable. It's not a slam, I'm just saying that finding out the in depth method of operation for a given system can often be rewarding.
deleted 10y ago
[deleted]

countingteeth 10y ago

Ya'll are beyond parody. It was added to CVS two months ago? Yay. I'll be sure to upgrade and rebuild from dev in CVS. Call me when doas has finished reimplementing sudo, oh so much better and more auditably.

notaplumber 10y ago
It's was never intended to completely replace sudo, but now you're just pulling teeth.
- countingteeth 10y ago
  It wasn't? Then why did they? As I've repeatedly reminded, sudo is in ports. I thought credential caching was left out because it was another unnecessary bloated feature creep and doas is supposed to be minimal and more secure. Apparently people couldn't live without it, and it's added in three releases later.
  - notaplumber 10y ago
    If you followed development, sudo in OpenBSD was maintained by Todd C. Miller, the same person who maintains the sudo.ws version. The version in OpenBSD was years behind and had many features stripped out or disabled. It was a maintenance burden and people wanted the upstream version in ports to get features like plugins, LDAP, etc.
sctb 10y ago
We detached this flagged subthread from https://news.ycombinator.com/item?id=13065270 https://news.ycombinator.com/item?id=13065270.

elchief 10y ago

Ports might be unaudited, but OpenBSD base has lots of useful stuff that many people don't know about. Like OpenBSD's own web server, LDAP server, IPSEC/VPN implementation, time server ... All priv-sep'd, simplified, pledged Also, these days the preferred MTA is OpenSMTP, and the preferred name server is NSD

atmosx 10y ago

Out of curiosity, anyone ever worked with an hardened OpenBSD or Linux + GRSec server farm? How do you handle updates? It must a sysadmin deployment nightmare.

micaksica 10y ago
It's not that bad once you have it set up. PaX causes most issues. You run a custom repo with two packages, your compiled linux-grsec kernel, and a package that contains paxd and paxd exceptions for your typical binaries. Once you find a stable grsecurity kernel config you don't really have much to worry about. When new updates are released, test them on your test tier with your existing PaX rules and exemptions, and if they pass tests push them into prod. Worst case scenario you disable PaX (and its memory protections) in emergency cases or rollback to the known good version. If you are running "unattended-upgrades" or something else and letting your tiers autopatch themselves, well, that's dangerous to stability in and of itself. I run -grsec-patched kernels on all of my personal workstations as well. That's when grsec can be a pain.
Gracana 10y ago
I do manual upgrades on my machines because I only have a few and they're different enough that automation wouldn't help, buuuut... You can use release(8) and autoinstall(8) with pxe to deploy create and deploy OpenBSD upgrades/installs. In between releases, you can follow the -stable branch of the ports tree and use dpb(1) to generate updated binary packages, which all your machines can then install.
milcron 10y ago
I don't operate a server farm but OpenBSD updates are pretty easy. Just do `pkg_add -Uu`. If your dependencies are minimal, keeping OpenBSD up-to-date is actually pretty relaxing. Don't need to install security patches all the time as with Linux.
- countingteeth 10y ago
  pkg_add -Uu won't address a single update under https://www.openbsd.org/errata.html https://www.openbsd.org/errata.html , i.e. the very most important ones. Also as far as I know pkg_add still doesn't know about restarting services, so vulnerable processes will be left running.

gbrown_ 10y ago

I would simply say OpenBSD runs. It runs with it's hardening mechanisms always on. Ports are considered in whether a new mechanism or aggressiveness of an existing mechanism is suitable. The idea is to have a platform where good quality software runs and bad quality software crashes. See the evolution of the default malloc.conf options or more recently the explicit enforcement of W^X. It's true OpenBSD was not founded with the intention of being "the secure OS" but the ethos of designing secure software is very much something that is core to the developers today. Others have already pointed out cons as well as pros of MAC style systems which this post laments the lack of in OpenBSD. I'll simply say I prefer the approach of pledge. Yes you need to build it into the application but I think that kind of upfront explicitness is better than a policy system and I hope other platforms adopt it.

wyager 10y ago

> There is no good reason to avoid implementing extended access controls when the greater security and control they provide is irrefutable. Disagreed. MAC is a crutch and a hack, not a solution. We should prefer not to rely on half-assed, overcomplicated, and formally unverifiable palliative measures. If you want security, you fundamentally must use secure software. No amount of sandboxing or access control wrapped around a vulnerable garbage heap is going to stop the garbage heap from getting hacked in the first place.

nickpsecurity 10y ago
There were numerous examples of MAC, esp SELinux, stopping vulnerabilities. There's also plenty of examples of bugs and vulnerabilities in software with OpenBSD even fixing bugs regularly. The claim that one should reduce bugs and have damage limitation to reduce overall risk is rock solid with proof in the field. The refrain of OpenBSD supporters is, "It's not necessary and won't help..." The reality in field deployments, "It was and did." QED.
- wyager 10y ago
  > There's also plenty of examples of bugs and vulnerabilities in software with OpenBSD even fixing bugs regularly. As the OpenBSD devs will tell you, there have only been two known vulnerabilities in default OpenBSD installs in the history of OpenBSD. This strongly suggests that having decent software quality is an effective way to prevent vulnerabilities from existing in the first place. > The refrain of OpenBSD supporters is, "It's not necessary and won't help..." No, the refrain is "it's better to spend effort curing the disease than treating the symptoms". If we put half the effort we put into palliative defense measures into formal verification or doing things right the first time, I suspect it would be drastically more effective.
  - nickpsecurity 10y ago
    "As the OpenBSD devs will tell you, there have only been two known vulnerabilities in default OpenBSD installs in the history of OpenBSD. This strongly suggests that having decent software quality is an effective way to prevent vulnerabilities from existing in the first place." I addressed that myth in my main comment. See here: http://pastebin.com/6cW3FyJE http://pastebin.com/6cW3FyJE They just assess and count differently than most folks. ;) " If we put half the effort we put into palliative defense measures into formal verification or doing things right the first time, I suspect it would be drastically more effective." I agree being on side of high-assurance security. OpenBSD doesn't so I don't know your statement supports what they do. They systematically avoid formal verification like what you described, safer languages, coding styles for static analysis, etc. It's people from my side of things promoting or building on those. They just hunt bugs in C code by eye and hope their probabilistic mitigations always work. Totally different.

deleted 10y ago

[deleted]

module0000 10y ago

What mission critical systems is OpenBSD running anywhere? I'm talking about the OS itself, not one of the pieces of software developed as part of the project and ported to other platforms(eg openssh). Not trolling, but genuinely curious where OpenBSD is running outside of our basements.

milcron 10y ago
Users don't have to reveal themselves, but there's a list available at https://www.openbsd.org/users.html https://www.openbsd.org/users.html I see lots of academies, ISPs, and even Adobe is in there,
nickpsecurity 10y ago
Genua on milcron's list is probably most significant. They are a defense contractor that sells firewalls, VPN's, data diodes, etc for business and government (including military). You can bet significant applications are protected with them. This is the kind of role most of its users put it in. Others just use it like any other server OS with better reputation for reliability and security. Less patching... a time-consuming activity... at the least. Last one was similar reason for adoption of Argus Pitbull and SELinux w/ Tresys tools in their niches. Less worries when malware is going viral on the Internet and in media. ;)

nickpsecurity 10y ago

Interesting for this post to turn up as I was drafting and getting review for my own rebuttal to OpenBSD propaganda on Schneier's forum. I couldn't find it as I needed it. (shrugs) Quick attempt at redoing it here. Started with this on Lobste.rs forum that's popular for OpenBSD developers: https://home.nuug.no/~peter/blug2016/img1.html https://home.nuug.no/~peter/blug2016/img1.html Similar to some of the BS allthatiswrong counters. I'm just focusing on a few as it will already be a long writeup with many examples from history on where secure coding and UNIX really came from. In this Pastebin: http://pastebin.com/6cW3FyJE http://pastebin.com/6cW3FyJE