Live data from Hacker News

The Insecurity of OpenBSD (2010)

allthatiswrong.wordpress.com

11–20 of 88 posts

Re: The Insecurity of OpenBSD (2010)

#11
post #4

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 misconcep…

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.

Re: The Insecurity of OpenBSD (2010)

#12
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.

Re: The Insecurity of OpenBSD (2010)

#13

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.

MACs come in many different flavors. E.g. AppArmor is very easy to administrate an provides security over running 'random' applications without MAC.

Re: The Insecurity of OpenBSD (2010)

#14

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.

MACs come in many different flavors. E.g. AppArmor is very easy to administrate an provides security over running 'random' applications without MAC.

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.

Re: The Insecurity of OpenBSD (2010)

#15

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…

>You upgrade one point release and suddenly sudo is not there any more...

That is not how OpenBSD release numbers work. 6.0 is no more a major version than 5.9.

Re: The Insecurity of OpenBSD (2010)

#16

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…

>You upgrade one point release and suddenly sudo is not there any more... That is not how OpenBSD release numbers work. 6.0 is no more a major version than 5.9.

How does that matter? Fact is you move from 5.7 to 5.8 and boom, no sudo. Check the release notes, and yeah, it's replaced with Ted's little side project. In 5.9 release notes it's "a little friendlier to use". Not as friendly as sudo, but ok, thanks, I guess?

Re: The Insecurity of OpenBSD (2010)

#17

Earlier quoted context omitted.

>You upgrade one point release and suddenly sudo is not there any more... That is not how OpenBSD release numbers work. 6.0 is no more a major version than 5.9.

How does that matter? Fact is you move from 5.7 to 5.8 and boom, no sudo. Check the release notes, and yeah, it's replaced with Ted's little side project. In 5.9 release notes it's "a little friendlier to use". Not as friendly as sudo, but ok, thanks, I guess?

if only shells had alias functions...

Re: The Insecurity of OpenBSD (2010)

#18

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…

For 2, syspatch is a coming item or you can use mtier.

"download and apply patches by hand to a source install"

What the heck? I just use cvs. Its really easy http://www.openbsd.org/stable.html

The upgrading is not really that hard. I'm really at a loss given I find FreeBSD a pain in the butt to upgrade since it always breaks something but have had no problem with OpenBSD other than not reading their man hard link instructions which didn't kill anything but was annoying.

Re: The Insecurity of OpenBSD (2010)

#19
post #6
post #2

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 thes…

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 clie…

ACLs are a terribly complex mechanism that would require a lot of new code added to the kernel

ACLs also make me as an administrator have to think much harder about, well, everything. Same problem with capabilities: each new layer increases the complexity of the reasoning required combinatorially ("so, the daemon isn't running as root, but it's in the daemon group, and the file has these capabilities, and those ACLs...")

Re: The Insecurity of OpenBSD (2010)

#20

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 w…

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.

Post reply on HN