Hacker News Reader

Comment by cedws | Hacker News Reader

The developer knows the program best - what files it needs to access, what syscalls it needs to make, etc.

What if the user doesn't trust the developer?

Out of scope—pledge is designed to allow developers to sandbox their own programs to deal with compromises. If someone finds a bug with your program that tricks it into opening an arbitrary file then pledge just saved you.

These sandboxing tools aren't designed to make it safe to run arbitrary untrusted code. If you want that then you're looking at a VM- either a full VM like firecracker or a software VM like V8.

So? You seem to be missing the minor premise in your comment which explains how having the knowledge of the program's inner workings translates into putting you in charge of deciding how to sand box it.

In fact I'd argue it's precisely the lack of such knowledge which makes sandboxing useful: after all, if I knew that the program won't touch or call anything sensitive, I would just simply run it as-is; contrariwise, if I knew it would steal my bank login info and send it to Serbia, I would just not run it at all.

EDIT: Don't get me wrong, I don't have anything against applications putting themselves into restricted modes, and splitting potentially sensitive logic into separate processes; but that functionality really should also be exposed to an end-user as well, akin to

    $ pledge --promises=stdin --chroot=/var/empty --cwd=/ -- suspicious_program

Nobody said there has to be one layer of sandboxing. Defense-in-depth approach is best. The developer can utilise sandboxing to limit the application's runtime abilities to what it should have, and the end user can further restrict the application to their preference using chroots/containers/jails.

Reply on news.ycombinator.com