The Insecurity of OpenBSD (2010) • Hacker News Board

Re: The Insecurity of OpenBSD (2010)

#81

Post by ori_b » Wed, Nov 30, 2016, 6:04 AM UTC

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.

But the binaries I want this on aren't services.

Re: The Insecurity of OpenBSD (2010)

#82

Post by aaronmdjones » Wed, Nov 30, 2016, 12:52 PM UTC

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.

You only need CAP_DAC_READ_SEARCH for backups.

Re: The Insecurity of OpenBSD (2010)

#83

Post by protomyth » Wed, Nov 30, 2016, 1:47 PM UTC

nickpsecurity wrote: post #72

dispose13432 wrote: post #56

Earlier quoted context omitted.

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

Which projects are doing this with SELinux?

Re: The Insecurity of OpenBSD (2010)

#84

Post by countingteeth » Wed, Nov 30, 2016, 3:06 PM UTC

notaplumber wrote: post #24

countingteeth wrote: post #12

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

> It lacks little "features" like credential caching This is wrong, see the 'persist' keyword. It was also implemented as a kernel assisted feature, rather than filesystem tickets. http://www.tedunangst.com/flak/post/doas-mastery http://marc.info/?l=openbsd-cvs&m=147283992915418&w=2

For some reason my post was deleted, but to repeat, you are pointing to a recent commit made to CVS.

Re: The Insecurity of OpenBSD (2010)

#85

Post by countingteeth » Wed, Nov 30, 2016, 3:16 PM UTC

milcron wrote: post #65

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.

pkg_add -Uu won't address a single update under https://www.openbsd.org/errata.html , i.e. the very most important ones.

Also as far as I know pkg_add still doesn't know about restarting services, so vulnerable processes will be left running.

Re: The Insecurity of OpenBSD (2010)

#86

Post by nickpsecurity » Wed, Nov 30, 2016, 3:48 PM UTC

protomyth wrote: post #83

nickpsecurity wrote: post #72

Earlier quoted context omitted.

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.

Which projects are doing this with SELinux?

I haven't followed SELinux in a while. I recall Tresys made tools with dialog boxes to make it about as easy as Windows firewalls. A quick Google leads me to Lobster being an example of what I was thinking of:

https://selinuxproject.org/files/2008_selinux_developer_summ...

Re: The Insecurity of OpenBSD (2010)

#87

Post by protomyth » Wed, Nov 30, 2016, 5:07 PM UTC

nickpsecurity wrote: post #86

protomyth wrote: post #83

Earlier quoted context omitted.

Which projects are doing this with SELinux?

I haven't followed SELinux in a while. I recall Tresys made tools with dialog boxes to make it about as easy as Windows firewalls. A quick Google leads me to Lobster being an example of what I was thinking of: https://selinuxproject.org/files/2008_selinux_developer_summ...

Given how fast pledge was able to be put into production, I think it was the right move. I get SELinux can and has (2008) had tools for this, but it really doesn't seem to have caught on.

Re: The Insecurity of OpenBSD (2010)

#88

Post by nickpsecurity » Wed, Nov 30, 2016, 11:43 PM UTC

protomyth wrote: post #87

nickpsecurity wrote: post #86

Earlier quoted context omitted.

I haven't followed SELinux in a while. I recall Tresys made tools with dialog boxes to make it about as easy as Windows firewalls. A quick Google leads me to Lobster being an example of what I was thinking of: https://selinuxproject.org/files/2008_selinux_developer_summ...

Given how fast pledge was able to be put into production, I think it was the right move. I get SELinux can and has (2008) had tools for this, but it really doesn't seem to have caught on.

SELinux was a demonstrator of Type Enforcement by Mitre. It got put into production because why not. There's simpler schemes out there for MAC even on Linux. I'd have recommended OpenBSD clean-slate something like them.

I do like pledge, though. I promoted API reduction a long time. Even deleting the code in kernel for appliances a la Poly2 project. Only so much can be gained with it, though.