peer-to-peer computation and security (was Re: [FoRK] kragen rides again-)

Kragen Javier Sitaker < kragen at > on > Fri Oct 13 11:06:05 PDT 2006

(quoting Tony's response in full because it doesn't seem to have made
it to the list)

On Thu, 12 Oct 2006 02:09:25 +0100, Tony Finch wrote:
> On Wed, 11 Oct 2006, Luis Villa wrote:
> > On 10/11/06, Kragen Javier Sitaker <kragen at> wrote:
> > >
> > > How are we going to solve this problem?  GNOME is going in the
> > > opposite of the right direction.  Mono is implementing Microsoft's
> > > security model, which is useless for P2P computation.  The
> > > capabilities guys are becoming gradually more academic.  What are we
> > > going to do?
> >
> > I think someone has to go spec it and write it; that's the only way to
> > get real traction. I really haven't given much thought to the security
> > model, honestly. What is the problem with the mono security model in a
> > p2p context? [Perhaps a better question for where I'm at: what does
> > the language's security model have to do with the app's security
> > model, given that it will almost certainly have to create a p2p auth
> > system which doesn't really exist yet?]
> E sounds like it would be good in this area. <>
> It's a distributed object-capability language designed to support
> programming with fine-grained distrust and fine-grained message-passing
> parallelism.
> The problem at the moment is that privilege on most computers is
> all-or-nothing. If a computer is only used by one user, then if you
> compromise that account you effectively control the computer. We need to
> get away from the time-sharing multi-user model, where users are protected
> from each other, and move towards a model where applications are the unit
> of protection. Then it becomes easier to run untrusted code with limited
> privileges, without depending on a language runtime to protect you.

That's largely what I'm talking about, although Mono is definitely
trying to take the language-runtime approach, as does E.  As I said in
a recent message, I suspect that implementing this kind of protection
with multiple shared-nothing CPUs will likely be preferable to
implementing it with memory protection.

My understanding of the current .NET security system is pretty vague,
but here it is.  Software is divided into libraries (called
"assemblies") and you can have different levels of privilege for the
different libraries, and set up complicated ACLs determining which
libraries have access to what information.

(Perhaps someone more clueful can correct me on the above.  I'll
eventually get around to reading about that stuff on my own, though.)

The problem with security systems like this is that they embed the
policy into an unchangeable TCB, rather than providing mechanism and
leaving the policy up to application code.  The language of ACLs is
not a very expressive language in which to distinguish warranted
actions from unwarrranted ones.  Capability security allows
application software to define its own policies and create its own
trust boundaries, rather than having to select from a predefined set.

I think this kind of flexibility, to implement application-appropriate
security policies, is useful in general, but it's particularly crucial
when we're dealing with an area like peer-to-peer computation where
nobody has enough experience to make an informed guess what kind of
security policy to set in stone.

Mark Miller's dissertation, "Robust Composition: Towards a Unified
Approach to Access Control and Concurrency Control", which is largely
about E, goes into this at greater length, 229 pages:


    When separately written programs are composed so that they may
    cooperate, they may instead destructively interfere in
    unanticipated ways. These hazards limit the scale and
    functionality of the software systems we can successfully
    compose. This dissertation presents a framework for enabling those
    interactions between components needed for the cooperation we
    intend, while minimizing the hazards of destructive interference.

    Great progress on the composition problem has been made within the
    object paradigm, chiefly in the context of sequential,
    single-machine programming among benign components. We show how to
    extend this success to support robust composition of concurrent
    and potentially malicious components distributed over potentially
    malicious machines. We present E, a distributed, persistent,
    secure programming language, and CapDesk, a virus-safe desktop
    built in E, as embodiments of the techniques we explain.

> Tony.
> -- 
> f.a.n.finch  <dot at>

More information about the FoRK mailing list