Post by Toby Murray Post by Jed at Webstart
When a Unix system restarts all it's open file descriptors are
invalidated. It seems to me it might take some substantive work to
deal with that issue.
Consider Plash to be the union of a user's authority. At the
discretion of the user, they can invoke other applications and hand
them a subset of their authority with fine-grained controls allowing
the user to achieve almost least authority (except in the area of
network access which could be supported if Plash reified this in the
process's file namespace, so it's not impossible).
The user can define "executable objects" that comprise
1. an executable (eg. /usr/bin/mozilla-firefox)
2. a file namespace for the application (eg. /lib/ld.so,
/lib/libc.so, $HOME/.firefox/<variuos config files> etc.
What I take you to be saying is that Plash can manage permissions for
a Unix user by granting just POLA permissions to any program that the
user executes. That's fine (beyond the practical problems with
setting up such POLA restrictions - which I'll deal with
later). Since the executing program disappears when the system is
restarted anyway on current Unix systems, a reboot isn't a new issue
for any execution environment.
However, with regard to management of permissions for users (people)
on Unix, this seems to suggest that such management will continue to
be done with the traditional (standard) Unix user ids and permission
bits. This is somewhat problematic for POLA. Let's say you and I
both have accounts on some Unix system and we wish to work on a
shared project where we need some shared access to some resources -
let's say files. The traditional Unix means for such sharing is
through a shared group. Unfortunately, ordinary users can't create
such shared groups. I won't belabor these problems in Unix as I
believe they are well know.
However, now note that through the Plash mechanism I can set up a
process, you can set up a process and my process can send just POLA
access to resources to your process. I can dynamically start a
collaboration with you though such processes. However, when the
system restarts all such shared access goes away. I have to set it
up again after a system restart if desired.
Also, consider the issue of setting up commonly used permissions for
application execution. On capability system there typically exist
something like a "directory" where one can store named
capabilities. If Plash would somehow allow the creation of such
directories then one could imagine putting the resources needed for
any application to start up in a directory for the
application. Start it up and pass it the directory through Plash and
off it goes. However, how does one create such long lived containers
for capabilities on Unix with Plash? I don't see how to do it. If I
could, then I could create such a directory for the resources that we
need to share for our shared project and pass access to it to you through IPC.
Post by Toby Murray
These executable objects can survive a reboot. The user invokes the
executable object, which inokes the executable, handing it this
subset of the user's authority that is the namespace the user has
defined. While the file descriptors don't survive a reboot, consider
the filenames to be lambda names that map to capabilities in the
application's c-list. The application can access a capability in
their c-list by open() ing it's lambda name (the filename). Since
the namespace is persistent (because the executable objects are
persistent), the capabilities are too. It's just that the binding
from lambda name to capability re-occurs each time at runtime.
To me, this goes a hell of a long way to the virus immune desktop.
If I'm being to over optimisic, or am over-simplifying here, feel
free to step in and add some realism.
I agree with you that Plash can really help get closer to POLA for
Unix. I'm a big fan of Plash - Please don't misunderstand that. I'm
only pointing out that Plash by itself doesn't provide for solutions
for many of the POLA management problems that traditional capability
systems do provide solutions for. Namely the ephemeral nature of the
Plash supported "capabilities" (being Unix open file descriptors)
means that they are limited in what they can do. Useful to be sure,
but still limited in important ways.
Post by Toby Murray
Adam Langley's masters thesis is available here
His system is similar to DCCS in that it supports distributed
capabilities (via file descriptors), where the capability is proxied
at each end of a TCP connection. The file descriptor for the TCP
connection to the remote server acts as a proxy for the actual file
descriptor at the other end of the connection on the server to the
actual object being addressed. I believe that you did something
similar for DCCS to achieve distributed caps, although correct me if I'm wrong?
Thanks! I'm reading that paper with interest. I'll note some
comments while reading here:
Pg. 5 "Under our definition of capabilities the *-Property is indeed
enforced since no capability carrying channel exists between Alice and Bob."
I have to admit that this defense of the '*-Property' for a specific
form of capabilities seems a bit strained to me. With both ACLs and
with any form of capabilities we know that proxied 'serialization' is
possible (as Langley later does over TCP). To me any sort of strict
interpretation of the *-Property is a bit silly.
Pg. 8 'The requirements of the principle of least authority are
stated in [MK] as: "(1) split applications into
smaller protection domains, or 'compartments'; (2) assign exactly the
right privileges to each compartment;
(3) engineer communication channels between the compartments; (4)
ensure that, save for intended
communication, the compartments remain isolated from one another; and
(5) make it easy for themselves,
and others, to perform a security audit."'
At least POLP before it, and I have always assumed POLA, also applies
not just to execution environments, but to any sorts of authority
domains. In particular also and especially to people. The above
definition of POLA would seem to only apply to running computer
applications. As Langley says, "Further to software being flawed,
people are flawed too." - which makes the argument for POLA for
people as well as for software.
Pg. 11 R.e. the Burroughs 5000: There was nothing remotely
capability-like about the B5000, B5500, B6700 systems. In fact they
were so insecure that they depended on protection from their
compilers to generate "safe" code. If one could generate arbitrary
machine code on those systems and get it executed (as I in fact did)
then you could completely take over those systems.
Pg. 12 R.e. Dennis and Van Horn: "Although they were defining a
design, not describing a working computer..." Of course the PDP-1
system at MIT in the late 1960s and early 1970s was based on the
Dennis and Van Horn model and did in fact implement a capability system.
To skip then to "Contemporary Designs" without mention of systems
like RATS, GNOSIS/KeyKOS, NLTSS, Demos, Mach, Amoeba, and others
seems a bit of an oversight to me.
The key to this paper seems to be the requirements:
1. "We are developing this project because previous systems have had
too high a barrier to entry. All but one
of the previous contemporary designs have been operating systems and
it is our belief that common PC
hardware is now too diverse for a fresh-start operating system to
ever gain widespread acceptance. The
complexity in writing hardware drivers, which are vital if people are
going to be able to even boot an
operating system, is now prohibitive for all but the most well funded efforts.
2. Possibly more importantly, it's vitally important that current
applications continue to run without modifi-
cation and any new work can interact with this existing corpus of programs."
It's the last that is the real problem I believe. For example, in
our case with NLTSS we were able to overcome #1 above. We got a
system implemented that was at least as capable as the system it was
replacing (Drivers, etc.), but we found ourselves forced to emulate
exactly the API of the previous system we were replacing to, as
Langley says, "continue to run without modification ... with this
existing corpus of programs." What we found is that once we did so
we ended up with a system that looked in fact just like the previous
system but was somewhat slower due to the library level emulation of
the APIs. For example, we had a directed graph process structure and
we had to make it look like a tree structure. We had to provide a
server to support that view.
I look forward to seeing how Mr. Langley hopes to achieve these
objectives, but if I comment it will have to be in another message...