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

41–50 of 88 posts

Re: The Insecurity of OpenBSD (2010)

#41

Post by wyager »

> There is no good reason to avoid implementing extended access controls when the greater security and control they provide is irrefutable.

Disagreed. MAC is a crutch and a hack, not a solution. We should prefer not to rely on half-assed, overcomplicated, and formally unverifiable palliative measures.

If you want security, you fundamentally must use secure software. No amount of sandboxing or access control wrapped around a vulnerable garbage heap is going to stop the garbage heap from getting hacked in the first place.

Re: The Insecurity of OpenBSD (2010)

#42

Post by Gracana »

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 do manual upgrades on my machines because I only have a few and they're different enough that automation wouldn't help, buuuut... You can use release(8) and autoinstall(8) with pxe to deploy create and deploy OpenBSD upgrades/installs. In between releases, you can follow the -stable branch of the ports tree and use dpb(1) to generate updated binary packages, which all your machines can then install.

Re: The Insecurity of OpenBSD (2010)

#43

Post by xorcist »

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…

There has been no shortage of ways to escape Docker containers. If you want to lock down applications, SELinux will be much more useful, even if far from perfect.

Re: The Insecurity of OpenBSD (2010)

#44

Post by dispose13432 »

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

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.

While containers can't help against privilege escalation, they help against information leakage.

For example, even assuming privilege escalation isn't a possibility, www-user can read /etc/passwd, getting all usernames. Containers help mitigate this.

Re: The Insecurity of OpenBSD (2010)

#46

Post by protomyth »

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

Its definitely one of the things that shows up when you call about a lot of vendor's software support. I find it rather annoying that a company tells you to buy a specific Linux distribution then pulls exactly what you say.

Thinking about it (maybe because I am watching a update go as I type), what the heck does this say about how we program? I guess in some ways its why I like the idea of pledge. It makes me think better of the programmer because they have put some thought into their program. I'm not sure what I should think when I see SELINUX=disabled as a possible solution.

Re: The Insecurity of OpenBSD (2010)

#47

Post by toyg »

protomyth wrote: post #31
countingteeth wrote: post #23

Earlier quoted context omitted.

>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's has free updates?

CentOS has. RedHat is simply not free, so paid upgrades are par for the course. Any free distribution out there has free automatic updates - I think even Oracle came around.

> Mtier is free for the current version.

Yeah, for now (didn't use to be the case, might not be the case forever). Regardless, you're now trusting two entities, OpenBSD and MTier, rather than one. This second entity is not officially affiliated with OpenBSD, and they could shut down tomorrow. How do you trust someone like that with your most sensitive OS files?

I keep banging on about this, but it's the single item that prevents me from switching to OpenBSD as my "default deployed OS" for my generic web needs: the MTier situation is shady and undignified for a major project in 2016, let alone one built on security which requires trust; and my time is too valuable to waste it on reading release notes for banal patches and figure out what special-snowflake incantation I need this week. If OpenBSD does not have the capabilities to provide what MTier provides, they should broker an official agreement where MTier becomes the official channel for updates, with OpenBSD guaranteeing some quality control. If nobody wants to risk his reputation on this service, how can I ever trust it?

Re: The Insecurity of OpenBSD (2010)

#48

Post by youdontknowtho »

ams6110 wrote: post #38
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.

I'm an admin. Have been for many, many, moons. I've found that when things seen to behave that way it's because I have failed to sufficiently adjust my understanding of them. Often, we can be guilty of expecting that everything should behave like the least common denominator set of features between all host systems. Often, there is great value in finding "the way" that a particular system is trying to exemplify instead of forcing it to match my own.

To be fair, that least common denominator set of features can be very powerful and capable. It's not a slam, I'm just saying that finding out the in depth method of operation for a given system can often be rewarding.

Re: The Insecurity of OpenBSD (2010)

#49

Post by pmoriarty »

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…

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

A kernel exploit executed in a Docker container would compromise all the other Docker containers on the same machine (and the machine as a whole).

Re: The Insecurity of OpenBSD (2010)

#50

Post by protomyth »

toyg wrote: post #47
protomyth wrote: post #31

Earlier quoted context omitted.

> 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's has free updates? CentOS has. RedHat is simply not free, so paid upgrades are par for the course. Any free distribution out there has free automatic updates - I think even Oracle came around. > Mtier is free for the current version. Yeah, for now (didn't use to be the case, might not be the case forever). Regardless, you're now trusting two entities, OpenBSD and MTier, rather than one. This second entity…

Yeah, try to use CentOS when a vendor specifies Red Hat (all sorts of hell). So, I pay Red Hat. I did have a vendor that we didn't go with that specified Fedora but not Red Hat. The world is a bit weird, and I have no clue why that would make sense.

I haven't been screwed by MTier, but I would prefer a world where syspatch is done and working. So, I would guess the single item will fall away for you. Just a question of time I guess.

Although, if you don't read the patch notes for a lot of these OSes, you will get bitten in the butt. I got hosed by a combination of Microsoft and Oracle once. If I had read the notes I could have saved myself a weekend of WTF.

Post reply on HN