|
Don't add security, remove insecurity!
Lately i've been spending a lot of time studying (IE trying to grasp)
capability based systems. The basic idea is that each program in a
system has a set of capabilities, and can do nothing else in the system
(in fact doesn't even know any more about the system) then the
capabilities it has. To follow the example used in the
soon-to-follow-link, Solitaire has rights to make archives of your
confidential email and sell them on ebay, when all it really needs
is the rights to write to its window area, and save the highest score
for future program executions.
EROS looks to be one of the
only active capability based operating systems at the moment. The
design is actual quite fascinating, and includes system persistence.
(IE: pull the power plug out of the wall, plug back in and return to
the state before incident) Unfortunately, the documentation seems
to be sparse; several of the more practical parts of how the system
works have been more trouble to me then the theory.
Tonight i ran across a colloquium by Mike Miller, Building
a Virus-Safe Computing Platform Don\'t Add Security, Remove
Insecurity, which filled in a lot of the missing pieces. What
follows are some of the high points from the lecture.
-
Its informative to notice the subtle difference between
two ways of copying files:
cp foo.txt bar.txt
cat < foo.txt bar.txt
Invoking cp, you tell it what file paths you are interested in,
and it is responsible for opening those files. As such it needs all of
the permissions that you have, and you have to trust that its not
going to misbehave in the zillions of ways that it could. On the other
hand, cat is passed two file descriptors--it really doesn't
have to have access to anything else to do its job!.
-
Capability based systems are reliant on TCBs (trusted computing
bases) to delegate access. Each TCB has all the access it needs for
the domain its responsible, and passes those rights off to sub
processes on a need-to-know/need-to-do basis. Following the cat
example used above, the user's shell is a TCB, which has all the
rights of the user; it passes rights to read foo.txt and write
to bar.txt to the cat process.
-
Carefully designed TCBs and UIs can largely be coupled, again as
seen in the cat example. So rather then popping up windows
asking the user if they want to give such and such applet such
and such access (not to mention any names like java), the UI can
use the user interaction to provide data needed disseminate
capabilities.
-
Actually, this is true on a more fundamental level. Capabilities can
be passed around in the same way, and at the same time that normal
data references (object, whatever..) are passed around. Actually, this
is all that is needed for a capability system; any more and any less
erode the system. For example, if there are global variables in the
system, that is a mechanism for capabilities to be obtain and/or
distributed in non-need-to-know basis. Calls such as open(2)
are similar in nature in eroding the system.
-
Language/system designers usually think about security after they've
added features such as mentioned above, and then try to patch things
up by adding ad hocishness, rather then removing the impure features.
Combex, the company which
Mike Miller seems to be associated with, has a variety of papers and technology that might be of
interest.
[2004.06.08 05:26] |
[speeches/technical] |
#
|