Live data from Hacker News

The Insecurity of OpenBSD (2010)

allthatiswrong.wordpress.com

21–30 of 88 posts

Re: The Insecurity of OpenBSD (2010)

#21

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 there were a command like "pkg_add sudo".

Re: The Insecurity of OpenBSD (2010)

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

Re: The Insecurity of OpenBSD (2010)

#23

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

>For 2, syspatch is a coming item

Oh yes, another hand-rolled "coming item," in the world's most secure operating system. Someday, someday OpenBSD will support critical security updates that don't involve recompiling by hand. After all, we finally got "signify" for the base system. That wasn't important at all.

> or you can use mtier.

Right. That's called "on your own." I was going to preemptively predict someone would mention that, but the fact that paid consultants provide a critical feature for security updates as a service that every single serious Linux distro built-in for free is not a point in OpenBSD's favor.

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

Ahahaha. NO ONE outside the OpenBSD bubble would say that other than as a joke.

And are you not forgetting that many of the critical security patches do in fact involve a series of additional steps that must be performed separately, manually? If you don't actually READ each patch, you can miss a necessary step.

And of course little things like restarting patched services automatically or knowing when a reboot is required, well, that's an exercise to the reader.

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

I'm not using FreeBSD as a point of comparison here. I love OpenBSD. I also am not going to wave off how crippled it is operationally out of the box and basically unusable for production in many nontrivial real-world settings.

There's also the little issue of getting your head bitten off and shit on for no good reason even when you're only being helpful in the meekest and most good-faith possible manner, but that's only a little worse than par for the open source world.

Re: The Insecurity of OpenBSD (2010)

#24

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…

> It lacks little "features" like credential caching

This is wrong, see the 'persist' keyword. It was also implemented as a kernel assisted feature, rather than filesystem tickets.

http://www.tedunangst.com/flak/post/doas-mastery

http://marc.info/?l=openbsd-cvs&m=147283992915418&w=2

Re: The Insecurity of OpenBSD (2010)

#26

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.

It's was never intended to completely replace sudo, but now you're just pulling teeth.

Re: The Insecurity of OpenBSD (2010)

#27

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.

It's was never intended to completely replace sudo, but now you're just pulling teeth.

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.

Re: The Insecurity of OpenBSD (2010)

#28

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…

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.

Re: The Insecurity of OpenBSD (2010)

#29

Earlier quoted context omitted.

It's was never intended to completely replace sudo, but now you're just pulling teeth.

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.

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.

Re: The Insecurity of OpenBSD (2010)

#30
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

Post reply on HN