3 ms·

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

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.

trasz 8y ago
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.
- notaplumber 8y ago
  > 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.
  - loeg 8y ago
    What does it mean to sandbox a shell?
    - emaste 8y ago
      "Towards oblivious sandboxing with Capsicum" describes a capability-aware shell: https://www.engr.mun.ca/~anderson/publications/2017/towards-oblivious-sandboxing.pdf https://www.engr.mun.ca/~anderson/publications/2017/towards-...
      - loeg 8y ago
        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.
        emaste 8y ago
        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.
        loeg 8y ago
        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.
markjdb 8y ago
> 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)?
- throwaway2048 8y ago
  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.
  - emaste 8y ago
    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.

trasz 8y ago

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.

notaplumber 8y ago
> 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.
- loeg 8y ago
  What does it mean to sandbox a shell?
  - emaste 8y ago
    "Towards oblivious sandboxing with Capsicum" describes a capability-aware shell: https://www.engr.mun.ca/~anderson/publications/2017/towards-oblivious-sandboxing.pdf https://www.engr.mun.ca/~anderson/publications/2017/towards-...
    - loeg 8y ago
      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.
      - emaste 8y ago
        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.
        loeg 8y ago
        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.

markjdb 8y ago

> 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)?

throwaway2048 8y ago
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.
- emaste 8y ago
  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.