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

81–90 of 119 posts

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

#81

Post by legulere »

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…

The problem on android is that you'll have to agree to the list of privileges again in case of an update, so developers usually just grab all the privileges they might need in the future.

Also on Android the thread model is malicious Apps, while on OpenBSD it's trustable executables getting bugs exploited. Malicious Apps can trick with the privileges, exploits have to fight with the privileges that are already set.

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

#82

Post by justincormack »

mjn wrote: post #35
kentonv wrote: post #33

Earlier quoted context omitted.

No, I completely understand that that's the point of pledge. But De Raadt's own slide 5 makes a convincing case that "optional security is irrelevant", and he dismisses SE Linux on that basis. I don't see why the same doesn't apply to pledge. Don't get me wrong, I think it's great for this to be available and I would like to see a similar, easy-to-use seccomp wrapper available on Linux. But, sadly, app developers are…

I'm extrapolating a bit here, since it's not that clear from the slides whether this is precisely what he meant, but I interpreted him to be criticizing optional security on the user side, which SELinux is. Since it's a set of user-configurable local system policies, users can, and often do, just use the most permissive policy possible to avoid having to debug SELinux problems. pledge() is optional from the perspecti…

I don't see how pledge is different from Capsicum which he criticises on this basis, one it is compiled in you cant disable it.

(Incidentally Capsicum does seem to be coming to Linux, albeit slowly, and as a self sandboxing technique it is nice to use).

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

#83

Post by justincormack »

kentonv wrote: post #45
viraptor wrote: post #40

Earlier quoted context omitted.

You can open /dev/null at init time and then lock down open(). Sure - it's not always possible, but it's a solution.

That's definitely a way better strategy than what I said -- when your code is well-designed-enough for it to work.

That is the Capsicum model, disable open when you go into secure mode. Note you can allow passing of file descriptors and an external program can open new files for you if you allow this. Many single task programs do not need to open files after initialisation.

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

#84

Post by antocv »

kentonv wrote: post #19

Sounds like this could be implemented on Linux as a library on top of seccomp. I'm not impressed by De Raadt's objection to seccomp. BPF programs may technically be turing-complete, but most of the things pledge() does can be implemented by a pretty simple seccomp filter that's just a flat list of conditionals implementing a whitelist or blacklist. Meanwhile De Raadt points out, correctly, that voluntary security mec…

Oh hey sandstorm.io

I tried your stuff, and was discouraged by the "pipe this script which will make modifications to your personal operating system into bash", why cant you just make a normal package which extracts to / like every other software does?

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

#85

Post by INTPenis »

X-Istence wrote: post #52

One of the first things that sysadmins at my last place of work would do is turn off SELinux on new installs of RHEL. There were too many times that SELinux would cause issues for them because they didn't understand the built-in policies and where to place stuff. As a security conscious person, it is a HUGE pain in the behind and I've spent many hours debugging SELinux and it's policies.

That is unfortunately a bad practice but there also people out there who leave it in enforcing mode and actually make an effort to use it.

I think selinux use has increased lately, at least from my perspective.

Where I work I am constantly forcing it on people and volunteer to solve any problems they might have to ease their transition.

Just like pledge would require passionate developers who actually care about implementing pledge on the application level, SElinux requires passionate sysadmins who actually care about using it, and about their co-workers using it.

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

#86

Post by vidarh »

kentonv wrote: post #42
mjn wrote: post #35

Earlier quoted context omitted.

I'm extrapolating a bit here, since it's not that clear from the slides whether this is precisely what he meant, but I interpreted him to be criticizing optional security on the user side, which SELinux is. Since it's a set of user-configurable local system policies, users can, and often do, just use the most permissive policy possible to avoid having to debug SELinux problems. pledge() is optional from the perspecti…

In practice SE Linux policies are typically maintained by distros, which seems similar to OpenBSD adding pledge() to ports. I'll grant that pledge() will likely have an easier time expressing meaningful policies for many apps, though, since it is applied after initialization and with knowledge of command-line parameters, etc. OTOH, the set of policies expressible with pledge() is much more limited. But I really don't…

The problem with SELinux is that they often get turned off by admins at the first hint of resistance. E.g. Apache won't read from the non-standard directory you've decided to put your app in? Off goes SELinux.

Building in lowest common denominator checks in the applications that the app developer can know won't get in the way makes it less likely the checks will get disabled.

E.g. your web server could disable filesystem access to paths it doesn't need after having read its config files and determined where it's going to log and where it's going to serve files from, so that things keep working as expected for users, possibly making exceptions for really stupid things (like exposing /etc). That would reduce the chance that users start looking for ways to just turn it off.

That makes the two approaches complementary.

I agree with you that most app developers do not care, but that's besides the point for OpenBSD: They care, and they control most of their own userland.

And you don't really need "most" apps to do it anyway. We'd get far just by having most of the highest profile internet facing server applications support it.

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

#87

Post by leni536 »

tedunangst wrote: post #23
kentonv wrote: post #19

Sounds like this could be implemented on Linux as a library on top of seccomp. I'm not impressed by De Raadt's objection to seccomp. BPF programs may technically be turing-complete, but most of the things pledge() does can be implemented by a pretty simple seccomp filter that's just a flat list of conditionals implementing a whitelist or blacklist. Meanwhile De Raadt points out, correctly, that voluntary security mec…

How does one whitelist open("/dev/null") with seccomp-bpf?

AFAIK one can filter on the syscall's arguments.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

I think it's quite readable and one could modify it easily to whitelist open on "/dev/null".

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

#88

Post by throwaway2048 »

justincormack wrote: post #82
mjn wrote: post #35

Earlier quoted context omitted.

I'm extrapolating a bit here, since it's not that clear from the slides whether this is precisely what he meant, but I interpreted him to be criticizing optional security on the user side, which SELinux is. Since it's a set of user-configurable local system policies, users can, and often do, just use the most permissive policy possible to avoid having to debug SELinux problems. pledge() is optional from the perspecti…

I don't see how pledge is different from Capsicum which he criticises on this basis, one it is compiled in you cant disable it. (Incidentally Capsicum does seem to be coming to Linux, albeit slowly, and as a self sandboxing technique it is nice to use).

he is not critsizing capsicum as being optional, rather that it requires too much work and nobody bothers.

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

#89

Post by friendzis »

mrweasel wrote: post #70
friendzis wrote: post #64

Well, I have always thought that the best way to solve such problems are selective privileges. Android/iOS have privileges, though those are either all or nothing. Desktop basically has root/non-root. I think this problem should be solved not by the developer: I pledge to only read files, but the user/administrator: you are only allowed to read files; and attempts to do that could either fail hard on opening the file…

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 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.
Post reply on HN