Security

Laurent Martelli martelli@iie.cnam.fr
29 Dec 1998 01:06:37 +0100


>>>>> "Tril" == Tril  <dem@tunes.org> writes:

    Tril> ========================== User's view.

    Tril> 1. The system is open, the user can view every thing.  The
    Tril> system opens itself up for exploration.  Objects in the
    Tril> system are simple, intuitive, and documented.  The purpose
    Tril> of this is for the user to be able to understand his or her
    Tril> system by browsing around it.

    Tril> 2. The system is dynamic, the user can change every thing.
    Tril> The system provides tools for interacting with every part,
    Tril> changing it, by replacing components with equivalent ones.
    Tril> The user can also remove any part of the system that he or
    Tril> she doesn't want.

Hmmm, what about security and rights ??? 

My opinion is that security is an aspect in itself, should be be
treated independantly of others aspects. However, I do not yet have a
clear idea of how to implement this cleanly. 

I can see two ways to treat the problem : 

 o Meta-progamming : the "interpretor" is programmed so that it
 controls access to objects according to certain rules. Unices use
 PIDs to assign a privilege to each thread, with the possibility to
 change the PID under some conditions. The main drawback is that it is
 usually the default to transmit all the rights to the tasks, and
 allow for Trojan Horses. This is a real problem in a open system
 where you have to communicate with untrusted systems.

 o Proxies : Each "actor" of the system has his own view of the
 system. In order to communicate with other actors, an actor must
 explicitly publish an object to other actors. Publishing can be
 thought of providing firewall-proxies to other actors. But there's
 the same Trojan Horse problem since when you have a reference to a
 proxy, it can give you references to non proxy objects. So it is very
 hard to control access.

Laurent