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

71–80 of 88 posts

Re: The Insecurity of OpenBSD (2010)

#71

Post by nickpsecurity »

wyager wrote: post #41

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

There were numerous examples of MAC, esp SELinux, stopping vulnerabilities. There's also plenty of examples of bugs and vulnerabilities in software with OpenBSD even fixing bugs regularly. The claim that one should reduce bugs and have damage limitation to reduce overall risk is rock solid with proof in the field.

The refrain of OpenBSD supporters is, "It's not necessary and won't help..."

The reality in field deployments, "It was and did."

QED.

Re: The Insecurity of OpenBSD (2010)

#72

Post by nickpsecurity »

dispose13432 wrote: post #56
protomyth wrote: post #46

Earlier quoted context omitted.

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

>Thinking about it (maybe because I am watching a update go as I type), what the heck does this say about how we program? SELinux is not complex because we program in complex ways, but because we don't know the target program. For example, (again, nothing against Apache but...) if I want to secure Apache, there's no way for me (as a sysadmin) to tell exactly which files, exactly which syscalls, and exactly which libs…

You can do that in a SELinux-like system. There's been tools and policy languages for it. Even better, if the language is high-level & declarative, then it can be used to generate security policies on many different OS's and mechanisms instead of just SELinux or pledge.

Re: The Insecurity of OpenBSD (2010)

#73

Post by nickpsecurity »

bandrami wrote: post #10

Ah, the age old promise of MACs: perfectly secure, as long as you don't think very hard about the fact that somebody has to administer the access control rules.

It was straight-forward on the first system to use it: STOP OS on SCOMP & XTS-400. The STOP OS broke OS into various components layered by how privileged they were into four rings with user-mode software on lowest layer. Then, the ring protection by itself prevents (a) writes by untrusted programs to trusted programs' data or code spaces; (b) reads of secrets from privileged programs by untrusted programs. Anything security-critical is mediated by security kernel that is formally specified, verified, analyzed, tested, and pentested against a clear, security policy.

Complexity came when people wanted to apply MAC to poorly architected operating systems and programs. Especially monolithic UNIX. The LOCK program, which I link to in my main reply to OP, invented type enforcement in an effort to express vast majority of security policies for both their clean-slate, high-assurance TCB plus the UNIX VM's they were making for compatibility. Got applied to a BSD in Sidewinder firewall, then applied to microkernels at Utah in form of Flask architecture, and then ported as SELinux to Linux. As you can see, a series of tough compromises from Linux's insecure design plus the fact it was basically an academic hack led to its complexity and issues.

Simpler ones included LOMAC, rule-set based methods, Windows Integrity Control (similar to STOP's), and so on. TOMOYO and AppArmor at least did a learning mode that acceptance testing could feed. Capsicum brings capability-security model to FreeBSD on top of SEBSD enhancements. It's not kludgy MAC or nothing. There's middle ground.

Re: The Insecurity of OpenBSD (2010)

#74

Post by nickpsecurity »

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…

This two schools of security isn't accurate. The original approach to security, devised by the inventors of INFOSEC, was doing all of these things:

http://pastebin.com/xZ6m4T8Z

Most vendors and FOSS ignored them despite those methods getting consistently-great results but preferred method not doing so. They then pick and choose among lowest-level techniques for verification. They also slowly relearned independently some of the vast body of security engineering knowledge they're ignoring to this day.

In this case, one camp is about trying to make code in an insecure language perfect with probabilistic mitigations to stop problems. Another barely cares about code security but uses strong measures for containment to hopefully limit damage. Author of OP supports doing both as far as I can tell. High-assurance supports doing what was proven, mathematically and empirically, to get the job done going back to the 1960's-80's extended with what we've learned today. Commercial, CompSci, and a few FOSS projects attempt various levels of adoption of such techniques with safety-critical proprietary (eg aerospace, trains) doing it the most.

"There's not enough data / samples of secure operating systems to make an intellectually honest assertion that one approach is definitively superior"

There really is. Certain methods I outlined consistently worked better. Others didn't. OpenBSD avoids most of what worked outside code review, hardening, and pledge then continues to use language and architecture proven to cause problems vs alternatives for UNIX compatibility. One can definitely make predictions from that about kinds of issues they'll face or upper limits of assurance that can be provided.

Re: The Insecurity of OpenBSD (2010)

#75

Post by waspleg »

milcron wrote: post #6
tptacek wrote: post #2

OpenBSD by itself contains a feature set similar in comparison to the GRSecurity patch for Linux without the ACL or RBAC implementation. GRSecurity and the Openwall project actually pioneered many of the protections that occurred later in OpenBSD such as Executable Space Protection, chroot restrictions, PID randomization and attempts to prevent race conditions On the one hand: I think OpenBSD did pioneer some of thes…

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…

I was very fond of OpenBSD 20 years ago when I ran it (still have the t-shirt). It had a simple elegance that struck a chord with me. I haven't looked at it in a long time, the last time I looked it didn't support VMs at all and didn't plan to which was a deal breaker ;/

I've never heard of pledge so went looking to find out what it is and found Theo's presentation: https://www.openbsd.org/papers/hackfest2015-pledge/mgp00001....

Re: The Insecurity of OpenBSD (2010)

#76

Post by bandrami »

dom0 wrote: post #52
bandrami wrote: post #14

Earlier quoted context omitted.

There's two separate issues here, both of which apply: 1. A knob that can't be configured can't be misconfigured (IIRC Debian had a hole in its default selinux config for years that created a vulnerability selinux-less machines didn't have) 2. (This was more what I meant) the promise that makes people like MACs is that you no longer need a single all-powerful root user to do everything (this bleeds into ACLs and capa…

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

Which leads us to the full absurdity of CAP_SYS_ADMIN, which at this point even the kernel team admits is "basically root"

Re: The Insecurity of OpenBSD (2010)

#77

Post by bandrami »

dom0 wrote: post #61
ori_b wrote: post #60

Earlier quoted context omitted.

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.

GNU PIES, however, does check its own privileges. I have no idea why it didn't get a harder look during the init wars. I get that Shepherd "isn't there yet", but IMO Pies is.

Re: The Insecurity of OpenBSD (2010)

#78

Post by wyager »

nickpsecurity wrote: post #71
wyager wrote: post #41

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

There were numerous examples of MAC, esp SELinux, stopping vulnerabilities. There's also plenty of examples of bugs and vulnerabilities in software with OpenBSD even fixing bugs regularly. The claim that one should reduce bugs and have damage limitation to reduce overall risk is rock solid with proof in the field. The refrain of OpenBSD supporters is, "It's not necessary and won't help..." The reality in field deploy…

> There's also plenty of examples of bugs and vulnerabilities in software with OpenBSD even fixing bugs regularly.

As the OpenBSD devs will tell you, there have only been two known vulnerabilities in default OpenBSD installs in the history of OpenBSD. This strongly suggests that having decent software quality is an effective way to prevent vulnerabilities from existing in the first place.

> The refrain of OpenBSD supporters is, "It's not necessary and won't help..."

No, the refrain is "it's better to spend effort curing the disease than treating the symptoms". If we put half the effort we put into palliative defense measures into formal verification or doing things right the first time, I suspect it would be drastically more effective.

Re: The Insecurity of OpenBSD (2010)

#79

Post by nickpsecurity »

wyager wrote: post #78
nickpsecurity wrote: post #71

Earlier quoted context omitted.

There were numerous examples of MAC, esp SELinux, stopping vulnerabilities. There's also plenty of examples of bugs and vulnerabilities in software with OpenBSD even fixing bugs regularly. The claim that one should reduce bugs and have damage limitation to reduce overall risk is rock solid with proof in the field. The refrain of OpenBSD supporters is, "It's not necessary and won't help..." The reality in field deploy…

> There's also plenty of examples of bugs and vulnerabilities in software with OpenBSD even fixing bugs regularly. As the OpenBSD devs will tell you, there have only been two known vulnerabilities in default OpenBSD installs in the history of OpenBSD. This strongly suggests that having decent software quality is an effective way to prevent vulnerabilities from existing in the first place. > The refrain of OpenBSD sup…

"As the OpenBSD devs will tell you, there have only been two known vulnerabilities in default OpenBSD installs in the history of OpenBSD. This strongly suggests that having decent software quality is an effective way to prevent vulnerabilities from existing in the first place."

I addressed that myth in my main comment. See here:

http://pastebin.com/6cW3FyJE

They just assess and count differently than most folks. ;)

" If we put half the effort we put into palliative defense measures into formal verification or doing things right the first time, I suspect it would be drastically more effective."

I agree being on side of high-assurance security. OpenBSD doesn't so I don't know your statement supports what they do. They systematically avoid formal verification like what you described, safer languages, coding styles for static analysis, etc. It's people from my side of things promoting or building on those. They just hunt bugs in C code by eye and hope their probabilistic mitigations always work. Totally different.

Re: The Insecurity of OpenBSD (2010)

#80

Post by dispose13432 »

yarrel wrote: post #67
ams6110 wrote: post #35

Earlier quoted context omitted.

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.

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

Quicker, but not cheaper

Post reply on HN