3 ms·

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

> 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
> 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.
- brynet 8y ago
  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 https://man.openbsd.org/socket
  - markjdb 8y ago
    Ok, so that's tighter than what I said, but my point still stands.

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

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

brynet 8y ago
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 https://man.openbsd.org/socket
- markjdb 8y ago
  Ok, so that's tighter than what I said, but my point still stands.