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

31–40 of 88 posts

Re: The Insecurity of OpenBSD (2010)

#31

Post by protomyth »

countingteeth wrote: post #23
protomyth wrote: post #18

Earlier quoted context omitted.

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

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

Red Hat's has free updates? I was unaware of that. Mtier is free for the current version.

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

I have to patch Windows, FreeBSD, OS X (excuse me Mac OS), Red Hat, and Windows for my current job. I really don't get the problem with OpenBSD. I'm no super system admin. You have to read the patch notes with all of them so I thought it was normal. If you don't read the patch notes, you will end up in a world of hurt. Red Hat had some serious issues with the stupid software vendor that requires me to have Red Hat.

I'm not saying OpenBSD is perfect or even great, I just don't think it's that bad when compared to what I have to do with other servers.

Now, if you want bad patches, deal with "enterprise educational software" that requires me to run an 762 megabyte SQL file against an Oracle database then move files to specific locations.

Re: The Insecurity of OpenBSD (2010)

#32

Post by upofadown »

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

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

The comment you are replying to does not mention auditing.

Re: The Insecurity of OpenBSD (2010)

#33

Post by milcron »

tptacek wrote: post #8
milcron wrote: post #6

Earlier quoted context omitted.

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…

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

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.

Re: The Insecurity of OpenBSD (2010)

#34

Post by milcron »

jlgaddis wrote: post #9
milcron wrote: post #6

Earlier quoted context omitted.

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…

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

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.

Re: The Insecurity of OpenBSD (2010)

#35

Post by ams6110 »

djsumdog wrote: post #28
dispose13432 wrote: post #20

Earlier quoted context omitted.

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

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

   SELINUX=disabled

Re: The Insecurity of OpenBSD (2010)

#37

Post by rwj »

djsumdog wrote: post #28
dispose13432 wrote: post #20

Earlier quoted context omitted.

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

I'm not sure that containers will help with security profiles. They should help with (for example) privilege escalation, but you will still be left with managing what systems/programs need access to what resources.

Re: The Insecurity of OpenBSD (2010)

#38

Post by ams6110 »

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…

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.

Re: The Insecurity of OpenBSD (2010)

#39

Post by micaksica »

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.

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.

Re: The Insecurity of OpenBSD (2010)

#40

Post by gbrown_ »

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.

Post reply on HN