From mboxrd@z Thu Jan 1 00:00:00 1970 From: crossd at gmail.com (Dan Cross) Date: Sun, 8 Jul 2018 22:44:23 -0400 Subject: [COFF] Other OSes? In-Reply-To: <20180708163150.0c9e1870@jabberwock.cb.piermont.com> References: <20180705055650.GA2170@minnie.tuhs.org> <20180708163150.0c9e1870@jabberwock.cb.piermont.com> Message-ID: On Sun, Jul 8, 2018 at 4:31 PM Perry E. Metzger wrote: > [snip] > On Wed, 4 Jul 2018 23:40:36 -0700 Bakul Shah > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: