Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Insecurity of OpenBSD (2010)

allthatiswrong.wordpress.com

Post reply on HN
Print view View original

61–70 of 88 posts

Re: The Insecurity of OpenBSD (2010)

#61

Post by dom0 »

ori_b wrote: post #60
dom0 wrote: post #52

Earlier quoted context omitted.

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

Even better, in my opinion, is that many of the caps that you would use to sandbox an app (like PID and FS namespaces) require you to have the sysadmin capability set on the process. Great. You need to give a process more or less root so that it can deny itself privileges.

The idea is probably that the service manager (systemd) manages the NSs for the applications contained therein. systemd of course doesn't have to check it's own privileges.

Re: The Insecurity of OpenBSD (2010)

#62

Post by milcron »

dom0 wrote: post #53
milcron wrote: post #34

Earlier quoted context omitted.

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.

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

He said that in ~2007? So that may be correct. x86 hardware virtualization has gone through several generations so his comments may have remained accurate even as hardware features were added.

Hardware-assisted virtualization really took off in ~2008, but they've continued to add features over the past decade.

https://en.wikipedia.org/wiki/X86_virtualization

Re: The Insecurity of OpenBSD (2010)

#63

Post by milcron »

module0000 wrote: post #55

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.

Users don't have to reveal themselves, but there's a list available at https://www.openbsd.org/users.html

I see lots of academies, ISPs, and even Adobe is in there,

Re: The Insecurity of OpenBSD (2010)

#64

Post by [deleted] »

youdontknowtho wrote: post #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…

[deleted]

Re: The Insecurity of OpenBSD (2010)

#65

Post by milcron »

atmosx wrote: post #36

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.

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.

Re: The Insecurity of OpenBSD (2010)

#66

Post by hannob »

hhw wrote: 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…

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

There is no principle reason why these two philosophies - fixing bugs and explit mitigations - collide. You can strive for both - and I'd argue that that's probably what most infosec people would support. OpenBSD also does quite a bit of exploit mitigation, so they're not clearly on a "bug fixing" philosophy either.

I know Spender has a pretty extreme position in saying that fixing bugs is almost irrelevant. But I'd say he's an extreme voice in that debate.

Re: The Insecurity of OpenBSD (2010)

#67

Post by yarrel »

ams6110 wrote: post #35
djsumdog wrote: post #28

Earlier quoted context omitted.

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

The typical configuration I see in /etc/selinux/config is: SELINUX=disabled

It's quicker to recover from a hack than it is to deal with SELinux every day.

Re: The Insecurity of OpenBSD (2010)

#68

Post by splesjaz »

dispose13432 wrote: post #20
HugoDaniel wrote: post #5

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…

While SELinux enabled distros usually comes with a targeted mode by default Gentoo hardened has strict mode in it's policy rules, everything is confined with that policy.

Usually only targeted applications are confined by default and allowing unconfined applications to run without any protection.

Apparmor is easy and anyone can understand how it works after reading the wiki, while apparmor also has neat functions you need to compile them in sadly :(

OpenBSD is great, first you can leave it running for a long time without thinking about security bugs or updates, instead Linux you have to keep close eye to kernel updates & application patches, that's why things like mailservers & DNS & NTP and more are running OpenBSD because I know it doesn't need critical updates every week and uptime is critical for me.

Re: The Insecurity of OpenBSD (2010)

#69

Post by nickpsecurity »

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

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

Re: The Insecurity of OpenBSD (2010)

#70

Post by nickpsecurity »

module0000 wrote: post #55

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.

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

Post reply on HN