[E-Lang] Re: Interaction Design for End-User Security

[Joerg Bornschein]

It seems the main discussion takes place on e-lang, so i'll 
forward my mail here...

Btw, reading your paper was very interesting! 

----- Forwarded message from Joerg Bornschein <joerg@zilium.de> -----

From: Joerg Bornschein <joerg@zilium.de>
To: eros-arch@eros-os.org
Subject: Re: [EROS-Arch] Re: [E-Lang] Re: Interaction Design for End-User Security

On Sat, Mar 17, 2001 at 10:56:22AM -0700, Marc Stiegler wrote:

> > The whole idea of executable installers is suspect. A declarative
> > package would be
> > far easier to verify. This could also give requirements as to shared
> > libraries, fonts, etc (including version information).
> > >From this information, a factory could be created. It is stated that a
> > factory has no capabilities -
> > this seems a bit broken. A factory can have capabilities that every
> > instance of the app will need.
> > Eg to shared libraries.  So the package manager would install these
> > capabilities into the factory.
> 
> This is a fascinating idea, and one I am embarassed not to have thought of
> myself. At first glance, I cannot think of an advantage to executable
> installers versus having a single installer as part of the TCB that
> interprets a declarative list of application requests/proposals for
> configuration (such as a nickname for the default pet name, for example).
> Perhaps there is some form of useful flexibility that an executable
> installer would bring to the table, but I can't think of one offhand.

I was thinking about a "package installation scheme" for some time but havn't
written down my ideas yet. I even wanted to code a prototype implementation
of a "software bank"... (by doing so, the "dont rescind memory a running process
 is using" - bug popped up. Btw, did somebody have a look?)

There are many neat possibilities -- but one has to be very careful here.

I think this "single installer" you mentioned should be thought of a
"software bank" which keeps track of the dependencies between the constructors
it handles. It should be able to construct(?) a sub software-bank.
This way it would be easy to seperate admin access to the global TCB and (maybe multiple)
application repositories (sound's a bit like virtual servers, doesn't it?)

there are many important issues to discuss.... maybe i'll post some ideas for a IDL
 such software bank could use later.


  joerg

_______________________________________________
eros-arch mailing list
eros-arch@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/eros-arch