[cap-talk] What are caps good for?
jed at nersc.gov
Fri May 7 14:29:49 EDT 2004
At 08:09 PM 5/6/2004, Jonathan S. Shapiro wrote:
>On Thu, 2004-05-06 at 21:07, Jed Donnelley wrote:
> > >In actual practice, we don't get attacked by commercial software. It
> > >isn't Windows or Word that is out to get you [I'll deal with penetration
> > >and scripts below in section 2].
> > Hmmm. I'm not sure I agee with the above. Word's macros are
> > notorious. I am afraid to open any Word document that I receive
> > with Word. I generally use Wordpad. I have a colleague that will
> > only open Word documents in a VMWare virtual machine that
> > does no have persistent state.
>Word != Word Virus. Word, the application, is not what attacks us. The
>typical scripting virus is "unstaked" software supplied by a third
>party. The failure in Word lies in incorrectly controlling the authority
>of the scripting environment.
The point I was trying to make is that all our applications, even if
we feel we can trust the vendor, need to have POLA applied to them.
In this case you say Word's "failure" is in incorrectly controlling
the authority of the scripting environment. Are you suggesting that
Word should do what the OS seems to be incapable of doing? With
Word the scripting environment runs in the environment of the user
just as Word does. That's where the problem lies in my opinion.
I think it entirely reasonable that Word would share it's appropriately
limited access rights with scripts/macros that it is asked to run.
There's a fundamental nut to the Trojan horse problem that is unsolvable.
If you have to trust an agent with something, the agent can abuse that
trust. I believe the major security/integrity problem in computing
(throughout the "ages") is the inability to limit such agents to POLA.
I believe an appropriate application of the capability concept/model
would solve this problem is so far as it can be solved, making a huge (!)
improvement in the security/integrity of computing.
I believe the discussion of "confinement" is nearly meaningless
except as a distraction that's counter productive. I believe providing
mechanisms and interfaces to support Principle Of Least Access
is where we should be focused. In principle such POLA restrictions can
be done with access lists. However, I believe access lists are very
awkward for this purpose. They seem to appeal to people largely because
of their ability to display who has access to a resource. However, in this
context people are thinking about which people have access to a resource.
There is also the thought that access rights in an access list can be
revoked at the list associated with the object. This putative value is
useless if the subjects are processes. I'm going to look at the access
list for my file and decide to revoke the right of process 5237 to the file?
I believe there are other more suitable mechanisms, using the capability model,
that can be used for rights revocation. Proxying is an adequate mechanism.
However, I believe that proxying is higher overhead than is needed. I
believe it is
more appropriate to have resource servers provide a "fork" mechanism that
a new capability like one already available except that it and all its
(restricted access versions, further forks, etc.) can be invalidated with a
to the server. Such bookkeeping in the server is relatively straight forward
and the mechanism provided is much lower overhead than proxying in such
situations. If you think about it, such a "forking" can go a long way to
the needs of "confinement". A Trojaned editor may give out my file capability
to other processes (e.g. directly or wall banging or whatever), but if, when
my editing session is complete, the rights that I gave to that process are all
invalidated, then relatively little harm is done (limited to damage to the
The appropriate place for proxying I believe is where semantic (presumably
value added) changes are being made to an object - whether to a single
object (e.g. a file becomes a directory) or with higher level services that
combine multiple objects into a higher level resource concept (e.g. a
file and access to a processor becomes a "process" object).
More information about the cap-talk