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

Pledge() – a new mitigation mechanism in OpenBSD

openbsd.org

Post reply on HN
Print view View original

101–110 of 119 posts

Re: Pledge() – a new mitigation mechanism in OpenBSD

#101

Post by mrweasel »

friendzis wrote: post #89
mrweasel wrote: post #70

Earlier quoted context omitted.

I think the point that the OpenBSD developers are trying to get across is that if privileges are left for the administrator to deal with, it doesn't get done in most cases. So that leaves the developers to deal with it. Also the developers know if a program needs to write to files or not. Why even leave it as an administrator task to lock down the program, if we already knew that it will never, ever need to write to…

Administrators (FOSS world) can chose where software is installed, what flags it is compiled with, etc., yet vast majority of us just apt-get/yum install and forget - trust the developers (not necessarily upstream) to chose sane defaults for us. The more paranoid use Gentoo/Slackware and fine-tune things themselves. But we are left with that option. Current semantics of pledge() do not leave us this option. There is…

>There is nothing wrong with shipping default privilege config file along with app

In principle no.

In the real world though, I think something else will happen. Someone tried to run a broken program. The solution suggested online will be: Just add/remove "this" in the configuration. Sure it fixes the immediate issue, but the fact is that program remains broken.

What "pledge" does is it requires the/a developer to fix the actual bug. The bug might be that the pledge call is wrong. Perhaps the program should have had more capabilities to start with. You just wouldn't know unless you read the code.

Re: Pledge() – a new mitigation mechanism in OpenBSD

#102

Post by glass- »

Arnt wrote: post #90

Why is pledge() int rather than void? All the examples exit() in one way or another, so why doesn't pledge() do that for them?

The examples are just examples, the uses in the tree are different. For example, ksh doesn't exit if pledge fails, it just prints an error about why it failed and keeps running (imagine how fun it would be the shell did just keep terminating). Other programs use their own logging to report the error, for example httpd logs the error the same way it logs all other fatal errors before it exits.

Re: Pledge() – a new mitigation mechanism in OpenBSD

#104

Post by davidgerard »

glass- wrote: post #94
Animats wrote: post #47

The problem with granular privileges is that programs want too many of them. See any Android flashlight app. Theo is getting good results on tightening up the classic UNIX command line tools. Has he tried EMACS yet? Also, a bigger problem than system calls is what parts of the file system the program can access. The concept that a program has all the privileges of its owner is the biggest single problem with permissi…

> Theo is getting good results on tightening up the classic UNIX command line tools. Has he tried EMACS yet? You may want to take a closer look at the slides about what has been pledged so far. httpd, smtpd, ntpd, relayd, slowcgi, xterm... They're not quite emacs, but they're also not just command line tools.

That's probably OpenBSD httpd, not Apache httpd - a vastly simpler creature.

Re: Pledge() – a new mitigation mechanism in OpenBSD

#105

Post by davidgerard »

pjmlp wrote: post #75
Animats wrote: post #47

The problem with granular privileges is that programs want too many of them. See any Android flashlight app. Theo is getting good results on tightening up the classic UNIX command line tools. Has he tried EMACS yet? Also, a bigger problem than system calls is what parts of the file system the program can access. The concept that a program has all the privileges of its owner is the biggest single problem with permissi…

Hence why I am a supporter that Apple and Microsoft keep pushing their sandboxing approaches, even with developers screaming along the way. Eventually we will get it right, because Theo is right, normal people will just disable security, because it is an hassle on their eyes. One just needs to search the online forums for people asking how to run as root on Mac OS X or Windows.

One of the most irritating things about Theo is that he keeps being right.

Re: Pledge() – a new mitigation mechanism in OpenBSD

#106

Post by mtgx »

pjmlp wrote: post #75
Animats wrote: post #47

The problem with granular privileges is that programs want too many of them. See any Android flashlight app. Theo is getting good results on tightening up the classic UNIX command line tools. Has he tried EMACS yet? Also, a bigger problem than system calls is what parts of the file system the program can access. The concept that a program has all the privileges of its owner is the biggest single problem with permissi…

Hence why I am a supporter that Apple and Microsoft keep pushing their sandboxing approaches, even with developers screaming along the way. Eventually we will get it right, because Theo is right, normal people will just disable security, because it is an hassle on their eyes. One just needs to search the online forums for people asking how to run as root on Mac OS X or Windows.

Exactly why I hate the argument that goes along the lines of "if people disable it, they must not want security!" - or if people buy cheap phones, they must not want it either - and so on.

The people are not at fault, and they don't know about these things. When the security is bad, it's a design problem - therefore, it's the system/platform/app developer's fault (although app developers are much less at fault than the platform developers, since they can also only control what's given to them by the platform vendor).

Re: Pledge() – a new mitigation mechanism in OpenBSD

#107

Post by pjc50 »

Animats wrote: post #47

The problem with granular privileges is that programs want too many of them. See any Android flashlight app. Theo is getting good results on tightening up the classic UNIX command line tools. Has he tried EMACS yet? Also, a bigger problem than system calls is what parts of the file system the program can access. The concept that a program has all the privileges of its owner is the biggest single problem with permissi…

"game, single player"

I don't think this is a permission set so much as it should be a security domain. At the moment we have the (user,group) tuple. The lesson of mobile OSs is that this needs to be (application,user,group) or possibly (vendor,user,group) - because the vendor/application developer is a potentially hostile actor.

Each app having its own "home" directory eliminates so many problems. It gives you a new problem, which is that apps are no longer composable. The solution to that is probably to put the work of choosing which applications are allowed to open which files back into the Finder/Explorer part of the system (which would be able to see everywhere) and let it do the opening.

Re: Pledge() – a new mitigation mechanism in OpenBSD

#108

Post by pjc50 »

mtgx wrote: post #106
pjmlp wrote: post #75

Earlier quoted context omitted.

Hence why I am a supporter that Apple and Microsoft keep pushing their sandboxing approaches, even with developers screaming along the way. Eventually we will get it right, because Theo is right, normal people will just disable security, because it is an hassle on their eyes. One just needs to search the online forums for people asking how to run as root on Mac OS X or Windows.

Exactly why I hate the argument that goes along the lines of "if people disable it, they must not want security!" - or if people buy cheap phones, they must not want it either - and so on. The people are not at fault, and they don't know about these things. When the security is bad, it's a design problem - therefore, it's the system/platform/app developer's fault (although app developers are much less at fault than t…

I think there's a slide to that effect in this presentation: that the development process involves upgrading the apps to the point at which the security can be made mandatory.
Post reply on HN