Hacker News Reader

Comment by notaplumber | Hacker News Reader

> Thing is, with pledge you never really know what the promises actually are, or if they make sense, in that you cannot work around them.

This makes no sense. Of course you know what the promises are, they're in the source code. You can also use ktrace/kdump(1) or even strings(1). The names of the promises are obvious and their intention is clear. There are subsets of POSIX.

> The assumption that with Capsicum you wouldn’t be able to sandbox stuff is blatantly false.

That is not what I said, I was specifically correcting your misinformed statement regarding pledge(2) and those programs that explicitly permit exec, like shells. Capsicum has no solution for this, and as such these programs cannot be sandboxed on FreeBSD.

View on HN

> The names of the promises are obvious and their intention is clear. There are subsets of POSIX.

That's true, but not really the whole truth. Take "dns", for instance. It enables a number of system calls needed to perform DNS resolution. But as far as I understand, those system calls (sendto(2) for example) can then be used arbitrarily. So "dns" actually permits more than the name implies.

On the other hand, when a program is running in capability mode, we know exactly what is permitted and what isn't.

> Capsicum has no solution for this, and as such these programs cannot be sandboxed on FreeBSD.

... they can't be sandboxed on OpenBSD either. pledge("proc exec") doesn't give you a sandbox.

Hi, that is not true. The "dns" promise only allows sockets with the SOCK_DNS option, the kernel restricts access to only DNS type operations and port numbers (enough for libc to do DNS). The kernel tries to separate pledges as tightly as possible, with many checks:

    SOCK_DNS
        For domains AF_INET or AF_INET6, only allow connect(2), sendto(2), or sendmsg(2) to the DNS port (typically 53).

https://man.openbsd.org/socket

Ok, so that's tighter than what I said, but my point still stands.

What does it mean to sandbox a shell?

"Towards oblivious sandboxing with Capsicum" describes a capability-aware shell: https://www.engr.mun.ca/~anderson/publications/2017/towards-...

What the paper describes isn't really a shell; it's just a launcher for running capsicum-naive programs in the capsicum sandbox:

> In its current implementation, the program is hardly a shell at all: it has no interactive mode, only executing a single program per invocation.

I don't know how you could meaningfully sandbox a shell without losing some functionality intrinsic to it being a shell.

What's required for something to be a shell? IMO a minimal shell would have some command line editing and parser, the ability to launch applications, job control, scripting ability, and I/O redirection. These can all be done in the context of a Capsicum-sandboxed shell, where the applications that can be run, and files that can be read/written by the shell, are only those explicitly made available to the shell.

If the result of your sandboxed shell is that it can run any program in PATH, which is sort of the basic function of a shell, then what is the value of the sandbox? I'd say one core feature is the ability to use su or sudo to escalate privileges and install a new application, and then run that application. If you have some whitelist of PATH applications at _start, that's impossible. Meanwhile, you can run dd or cc or rm or chmod and do whatever you like. So I'm just not seeing the value of sandboxing a shell.

I think there's a lot of value in sandboxing more constrained applications, especially with untrusted inputs, like web browsers, individual commands, etc. But I don't buy that you can meaningfully reduce the privileges of a shell without losing the quintessential features of a shell.

Reply on news.ycombinator.com