[cap-talk] RE: user interface issues - OS security discussion, restricted access processes, etc.

Jed Donnelley jed at nersc.gov
Thu Apr 29 22:24:30 EDT 2004

At 09:37 PM 4/26/2004, marcs wrote:

>> >>"getParent". Hence, any object that gets its hands on any
>> widget can
>> >>walk up the hierarchy of display components, replace the
>> icon in the
>> >>title bar with the quicken icon, change the title to
>> quicken, dump all
>> >>the existing widgets in the frame, transform it into a window that
>> >>looks just like a quicken window, and request the quicken password.
>> "password"??!  Strange stuff indeed.
>Hey, you want to work with legacy, you get to work with passwords :-)

This is certainly a minor point, but I wonder just what soft of password
one runs into when following up such a "getParent" trail.  Certainly
not a user password?  I'm unaware of any such password.

>One of
>the more entertaining things we encountered building the DarpaBrowser (a
>capability confining web browser that would work okay even in the presence
>of a malicious renderer)

That sounds like a useful effort.  Web browsers certainly seem likely
to continue to play a significant role in our future.  However, is the renderer
the most significant concern in Web browsers?

>is that HTML protocol embodies Confused Deputy
>attacks. Radical as I am, though, I don't have the strength to recommend
>replacing HTML :-).

There again I wonder what aspects of HTML embody such a Confused Deputy
threat.  Does it include the simple aspects that so much of the Web depends
on?  Certainly not the simple formatting aspects (<p>, <br>, <i>, etc.).
Is there something in the anchoring mechanism (e.g. <a ...) that creates
a hazard?

>> ...In my experience a lot (!)
>> of compatibility is needed to even get off the ground with a
>> production system.
>Years of being hit with brick walls and baseball bats convince me that,
>anyone with a bright vision of a different future grossly underestimates the
>needed amount of compatibility work.

For me this came home most forcefully when we had finished implementing
our capability based network operating system and putting it into production
at LLNL.  You would think there would be an institution where security would
be given a high priority.  Even with all the underlying tools in place for principle
of least access protections, we still ended up providing people with the user
interface that they were familiar with AND giving every process that a user
started up rights to every right that the human user had.

That model is broken.  Without coming up with new user interfaces that
correct that problem I don't believe substantive progress can be made.

Perhaps I should try to turn this thread around.  What sorts of user
interfaces are provided in the many capability based systems that
have been discussed in these threads?  Are there any that seem to be
responsive to the need I am pointing out?  If so then perhaps we can use
those as a model to help get today's workhorse systems moving in the
right direction.

Does anybody have any examples to present?

>However, there is something to be said
>for keeping  enough of the vision so that you don't wind up throwing it away
>for compatibility. I would say, find a way to run the old stuff in a box (as
>in, a virtual machine under EROS that lets MS Word macros corrupt the entire
>virtual machine, but who cares, it is a virtual machine), but let new stuff
>be built with toolkits that actually make sense, i.e., capability-oriented
>gui APIs. A capability API doesn't have to be a lot different from a
>well-designed object-oriented API. We have tamed both Swing and SWT. Over
>95% of what the Java programmer already knows is still correct in the
>capability oriented version. DotNet is tamable as well, at least 80% would
>be unchanged, I estimate.

If I could see some progress like that in the user interface (the human
computer interface) then I would feel that some progress was being made
on the front that I feel has been neglected.  Do you know of such progress?

>Any mechanism that ultimately sticks the user with a meaningless security
>dialog (like a query to the user when some object calls getParent one too
>many times) is a dead end. No security can be found down a path that makes
>the user spend his time making obtuse security decisions. The user has
>better things to do. He will choose insecurity if needed to get his work
>done with a minimum of security dialogs.

Hmmm.  I'm not sure I agree with the above, though I would like to explore
the consequences.

When a person starts a process it seems we all agree that it would be
desirable if that process was only given the rights it needs to do
what the user is requesting.  You say that "No security can be found
down a path that makes the user spend his time making obtuse security
decisions."  What about non obtuse security decisions?  What role does
the human user play in managing the rights given to programs that run
on the users behalf?

Certainly we want to provide as much assistance as possible in making
the "right thing" happen with as little user 'work' as possible.  That's why
I started down the path of associating something that knows what
rights an application should be given when it is initialized, e.g.

%vi stuff.txt

or double click on


or ...

Perhaps people are put off by even considering "legacy" systems
(namely the systems that I guess all of you are using to read and
reply to this email!).  If so, please suggest some user interfaces for
non legacy systems that we might be able to use as a model.  As
noted I worked on two capability based systems (RATS and NLTSS)
and both of them simply gave user applications all the rights that
the human user had (e.g. rights to a user home directory).  That
model is broken.  Do we agree on that?

What model do other systems use in this regard?  Perhaps (I
hope) there has been progress made in this are that I am just
unaware of.  If so them maybe we can use such interfaces as
a model that we can try to get moved into the systems that we
typically use regularly.

--Jed http://www.nersc.gov/~jed/ 

More information about the cap-talk mailing list