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?
The Insecurity of OpenBSD (2010)
21–30 of 88 posts
Re: The Insecurity of OpenBSD (2010)
#22It'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)
#23Much 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…
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)
#24Much 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…
This is wrong, see the 'persist' keyword. It was also implemented as a kernel assisted feature, rather than filesystem tickets.
Re: The Insecurity of OpenBSD (2010)
#25Call me when doas has finished reimplementing sudo, oh so much better and more auditably.
Re: The Insecurity of OpenBSD (2010)
#26Ya'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.
Re: The Insecurity of OpenBSD (2010)
#27Ya'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.
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)
#28Aren'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…
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)
#29Earlier 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.
Re: The Insecurity of OpenBSD (2010)
#30All priv-sep'd, simplified, pledged
Also, these days the preferred MTA is OpenSMTP, and the preferred name server is NSD