On Sun, Jul 8, 2018 at 4:31 PM Perry E. Metzger <perry(a)piermont.com> wrote:
[snip]
On Wed, 4 Jul 2018 23:40:36 -0700 Bakul Shah <bakul(a)bitblocks.com>
wrote:
- Capabilities (a number of OSes implemented them
-- See Hank
Levy's book:
https://homes.cs.washington.edu/~levy/capabook/
A fascinating resurrection of capabilities in a kind of pleasant
Unixy-way can be found in Robert Watson's "Capsicum" add-ons for
FreeBSD and Linux. I wish it was more widely known about and adopted.
- Namespaces (plan9)
A good choice I think.
Interestingly, it was in talking with Ben Laurie about a potential security
model for Akaros that I realized the correspondence between Plan9-style
namespaces and capabilities. Since Akaros had imported a lot of plan9
namespace code, we concluded that we already had the building blocks for a
capability-style security model with minimal additional work. I
subsequently concluded that Capsicum wasn't strong enough to be complete.
By way of example, I refer back to my earlier question about networking.
For example, rights(4) on FreeBSD lists CAP_BIND, CAP_CONNECT, CAP_ACCEPT
and other socket related capabilities. That's fine for modeling whether a
process can make a *system call*, but insufficient for validating the
parameters of that system call. Being granted CAP_CONNECT lets me call
connect(2), but how do I model a capability for establishing a TCP
connection to some restricted set of ports on a restricted set of
destination hosts? CAP_BIND let's me call bind(2), but is there some
mechanism to represent the capability of only being able to bind(2) to TCP
port 12345? I imagine I'd want to make it so that I can restrict the
network 5-tuple a particular process can interact with based on some local
policy, but Capsicum as it stands seems too coarse-grained for that.
Similarly with file open's, etc.
Curiously, though it wasn't specifically designed for it, but it seems like
the namespace-style representation of capabilities would be simultaneously
more Unix-like and stronger: since the OS only has system calls for
interacting with file-like objects (and processes, but ignore those for a
moment) in the current namespace, a namespace can be constructed with
*exactly* the resources the process can interact with. Given that
networking was implemented as a filesystem, one can imagine interposing a
proxy filesystem that represents the network stack to a process, but
imposes policy restrictions on how the stack is used (e.g., inspecting
connect establishment requests and restricting them to a set of 5-tuples,
etc).
- Dan C.