Hacker News Reader

Hacker News

Comment by jakeogh | Hacker News Reader

Full thread

jakeogh

I increasingly find myself looking at pledge...

https://man.openbsd.org/pledge.2

It's objectively the right model, if my assumptions are wrong, the program fails. I like that.

Maybe it could be taken further... to lie to the app and report back about it's sandbox... or halt and log it's image.

View on HN

pledge is objectively the wrong model, because it's an ad-hoc set of fixed-function rules. By contrast, Linux seccomp-bpf allows much more flexibility, because you can actually write an arbitrary program to implement whatever sandboxing policy you want.

In fact, your wish list highlights the problems of pledge precisely. You can implement "pretend to succeed" and "dump core for inspection by a trusted supervisor", but only on Linux with seccomp-bpf, not with pledge.

It's objectively the right model, because it's simple enough to implement that the vast majority of OpenBSD is pledged, including many ports like Firefox. The vast majority of other systems do not have the equivalent, in spite of having mechanisms that are in theory more powerful than pledge.

Flexible sandboxes don't help if your programs don't run in them.

Maybe it's objectively the right model for right now, and the wrong model for tomorrow, which would make you both right. It's hard to get programmers and packagers to add new OS specific features, at least until most OS's support from variant of that feature, and then they either bite the bullet or they use from library to abstract it.

Pledge is simple, and that helps people adopt it and start using it. When most operating systems are providing something equivalent and most programs are making some use of it, it then becomes a selling point to do it better, because the status quo has moved. At that point, pledge might not compare well, unless it has evolved.

> Maybe it's objectively the right model for right now, and the wrong model for tomorrow.

I'm using my computer right now. And pledge is evolving over time, as we gain experience in what real programs need by implementing protection for them.

Sure, but some things are hard to evolve after a while, and it may be that a clean (or older but more complex) implementation has advantages at some point. I have no idea if pledge will fall under this or not, but it's a common theme in computing.

Firefox is sandboxed via seccomp-bpf on Linux.

Awesome. I just checked, and it appears one FF process is, and one is not: https://bpaste.net/show/d8b3d6ada513

https://wiki.mozilla.org/Security/Sandbox/Seccomp

I would like much more general control, like disable write, or prevent forks, or net access, right from the executing shell. I have selinux experience, and it's too low level.

I think the idea behind pledge was that it's simple enough to be actually used whereas the Linux solution is technically superior but too complicated to be widely used.

I was not referring to the implementation. The first , should be a ;. I agree, bpf looks sweet. It might be so useful that it becomes optional only in spirit.

How many programs are running on your computer right now with seccomp-bpf policies?

As a complete aside, I'm happy that they added "execpromises" to pledge. It was one of the main things that really concerned me about its usage as a sandboxing system (seccomp I think is still more powerful but I will be the first to admit it's ridiculously complicated to get right).

Wonder how hard it would be to provide a Pledge API which simply passes through to seccomp.

It's possible, but it's fairly hard. You'd need a second process to supervise the seccomp'ed process, watching the paths that it accesses with ptrace, and allows/disallows the actions based on inspection of the process state.

The problem is that seccomp, as far as I'm aware, does not provide you with easy access to the actual arguments of system calls if they are not pointers. The actual pointed-at values of the arguments are required for emulating pledge.

Yeah, the seccomp limitation that it can't deref pointer arguments makes things a lot less elegant than pledge.

But at least unveil can be implemented via mount namespaces.

The need for ptrace is soon going to change with the new seccomp userspace notification API (still undergoing review) which allows a userspace process to get notifications when seccomp is tripped and decide what the return code of the syscall is (you can also give it an fd which is copied to the process unix socket style). This would allow you to use process_vm_{read,write}v without the need to mess around with PTRACE_SEIZE.

The main usecase for this is container runtimes (emulating privileged operations like auto-loading of kernel modules), but it could also be used for this an a whole host of other really neat features.

(Huge shout-outs to Tycho Anderson for working on this for quite a while!)

Reply on news.ycombinator.com