Hacker News Reader

Comment by notaplumber | Hacker News Reader

This weak argument from FreeBSD people is getting rather tiresome.

You can only call fork/exec if it's part of the pledge(2) promises, which you can later drop with subsequent calls to pledge. And with unveil(2) or even chroot(2) you can also place further restrictions on which binaries can be executed, and in which directories.

Systems like Capsicum would have you not be able to sandbox those programs at all. Users are left unprotected. So yes, if you pledge(2) a shell. It can call exec, but directly it can't call socket/connect(2), and the reduction of kernel attack surface is still significant. Software using privilege separation can safely leverage this.

View on HN

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. With Capsicum (or any other capability system) you can.

The assumption that with Capsicum you wouldn’t be able to sandbox stuff is blatantly false. The proof is existing code - Chromium, Tor, or Irssi - that has been capsicumized, often much more easily than with seccmp (I’ve not seen that comparison with pledge(2) yet).

One advantage that pledge(2) certainly has is the community involvement. OpenBSD has applied pledge(2) in many places, while capsicum(4) was quite a bit slower until recently. This has nothing to do with technical differences, and more with the social aspects.

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

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

> So yes, if you pledge(2) a shell. It can call exec, but directly it can't call socket/connect(2), and the reduction of kernel attack surface is still significant.

Why is that significant if I can fork and exec nc(1)?

because nc(1) is only pledged for fork and exec when you explicitly supply something for it to exec?, otherwise it takes codepaths that do not grant that pledge permission.

Having something be capcicumized (?) and exec capable seems to be mutually exclusive.

This isn't about nc's pledge call, this is about the thing that might call nc. A shell that is prevented from calling socket or connect, but can exec nc, is still able to establish a network connection.

Reply on news.ycombinator.com