[mrweasel]

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 a file, unless it's being exploited?

[friendzis]

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 nothing wrong with shipping default privilege config file along with app, but an option to say "f this shit, vim on my systems does not have access to sockets" without rebuilding from source would actually lead to better security.

[mrweasel]

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

[friendzis]

I understand this line of reasoning, though you can also find "solutions" like "disable SELinux". If we believe the bell curve then it should not be a surprise :) When it comes to security we basically have two options:

  * Delegate security configuration to developers, allowing them to open unpluggable holes
  * Delegate security configuration to users/admins, allowing them to shoot themselves in the foot

Developer can "fix" bugs by `pledge(EVERYTHING)` without actually finding the root cause, user can `privileges: ALL`, neither option protects us from foolishness. The core question is which option do we chose.

The most sane middle ground would be to allow users only to restrict privileges, not loosen up.

[throwaway2048]

it would only lead to better security when anyone bothered, which from decades of experience, we know to be essentially never.