[cap-talk] Re: "capabilities" as data vs. as descriptors
-OS security discussion, restricted access processes, etc.
Jed Donnelley
jed at nersc.gov
Thu May 6 15:23:02 EDT 2004
At 03:59 AM 5/4/2004, Jonathan S. Shapiro wrote:
>On Tue, 2004-05-04 at 05:33, David Wagner wrote:
> > David Hopwood writes:
> > >If
> > >we assume that all programs outside the TCB are maximally hostile,
> then there
> > >is no point in limiting direct transfer of authority, because a hostile
> > >program would bypass this by proxying the authority.
> >
> > Personally, I find this a much more convincing line of reasoning
>
>I do too, but I think there is also an important weakness.
>
>First, the notion of a single TCB is flawed. MarkM and I have long since
>stopped using this term in this way. There does exist in any given
>system a "universal TCB" (the set of stuff on which all programs
>depend), but this TCB is rarely the one we care about.
Agreed. I was interpreting the term relatively. That is, from the point
of me as a process my code is my "TCB".
>TCB is something that should be defined from an application perspective.
>It consists of the set of stuff on which that application depends.
Sounds like the above?
>Saying that "programs outside the TCB are maximally hostile" fails to
>recognize that programs in distinct applications operate with different
>incentives. They may all be hostile, but they may nontheless not be
>cooperatively hostile.
Doesn't this really just come back to POLA? If I have to ask another
process (domain) for something, I may well have to trust it with something.
E.g. I may trust a directory server to save a capability for me. I may
trust an editor to read and write a file on my behalf. I may trust a
shell or GUI with all my personal rights, etc. I don't want to trust the
editor with anything more than my file because it may be "maximally
hostile", but I certainly hope it isn't in most cases - for the benefit of
my file. If it turns out to be hostile, at least I've minimized the damage.
Does the term "TCB" = Trusted Code <or Computing?> Block (I assume)
have meaning in this context?
--Jed http://www.nersc.gov/~jed/
More information about the cap-talk
mailing list