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