[E-Lang] defense in depth

Marc Stiegler marcs@skyhunter.com
Thu, 25 Jan 2001 14:50:22 -0700

Hal, your proposed example here is upsetting to me, because it has
stimulated me to think of another example in which this sort of thing may
well be desireable :-)

Let me explain why your example is so upsetting to me first. Of all the
things used in computers today as alternatives to security, signatures on
code saying, "you can trust the code because you know the author and you can
trust the author" concerns me most. It concerns me because it gives the
"famous brands" a huge advantage over everyone else: No matter how much I
may dislike products by Microsoft, no matter how much I dislike EMACS as an
editor, there are reasons in each of these cases to believe that core
members of the project were interested in making the software not include
Trojan horses. So if I like the descriptions for John Podunk's Editor better
than either the EMACS editor or the Microsoft editor, I will still choose
not to use Podunk's editor because of the risks. Signed code plays into the
brands' hands. Capability security plays away from the brands's hands.

I just got running on my own system a demo of a malicious text editor, run
as a confined caplet, which poses no risks to my system or my confidential
data, because the only capability I grant it (through a standard dialog box
that is operated by the launcher, not the editor) is the capability to
read/write the file I want to edit (uh, I also grant it carefully
constrained powers to read keyboards and write windows). If Podunk wrote his
editor as a caplet, I'd be delighted to try it out.

There are parts of one's system one just has to give superpowers to, the
TCB. So branding is something you might care about for TCB items. Okay, I'd
already accepted that; there are only a couple of things that fall into this
category, the vast world of ordinary software applications do not fall into
this space.

But there is a span of apps, I'm not sure how large, that falls between the
word processor's tiny needs and the TCB's master-of-the-universe needs. For
these, branding may still be relevant, and I don't know how to fix it. The
particular example that has been slowly emerging in my head is the mail
management application, Eudora/Outlook/etc. Mail systems as currently
designed have a lot of power: They get to read all your confidential email,
read and edit your address book, send mail with your signature on it to
anyone they want, modify mail you're gearing up to send, and get
instructions from their authors through email they read before they pass it
on to you. Whew! An email system doesn't seem like it belongs in the TCB,
yet it is a powerhouse.

I talked about refactoring Web servers so that smaller components have fewer
powers, and Web servers as an example seem pretty clean. But I don't
currently see how to refactor the components in a mail manager while still
presenting a smooth user interface.

Hey, Ping, you guys had any thoughts on this matter? It looks from here like
a really great problem to solve. Until we can solve it, I guess John Podunk
better stick to writing word processors, and stay out of the mail management
business :-)


----- Original Message -----
From: <hal@finney.org>
To: <e-lang@eros-os.org>; <frantz@communities.com>;
Sent: Thursday, January 25, 2001 12:07 PM
Subject: Re: [E-Lang] defense in depth

> Would this be an example of defense in depth:
> I receive signed, mobile code from a remote system.  I compare the
> signature against a list of key holders I trust in order to decide to run
> the code.  As a further assurance, I only give the code capabilities to
> use those files which should be necessary for its operation.
> More concretely, suppose the company I work for authorizes only certain
> programs to be run on workers' machines, and it does so by issuing a
> signature by a company-controlled key on those programs.  Only if I see
> this signature will I allow the program to run on my machine.
> Now, if the capability system fails, I'm probably still OK because the
> mobile code is unlikely to be hostile since it was signed by someone
> I trust.  Or if the signature system fails (perhaps the signature key
> was stolen), the damage a malicious applet can inflict is limited because
> it only has capabilities appropriate to its task.  We have two defenses
> and both have to fail for catastrophe to occur.
> Would this form of defense in depth be appropriate for use in conjunction
> with a capability system?
> Hal
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang