3 ms·

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

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

by emaste 8y ago

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.