Security

[Tril]

On 29 Dec 1998, Laurent Martelli wrote:

> 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've been considering it a lot and it is an integral part of my model.
(which I have not posted here, I posted a quick version to unios' list,
which I will repost here soon)

> 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. 

Yes.  The "rules" you refer to are the specifications for an object's
type.  How secure the system is depends on how well the specifications are
followed in implementing instances of that type.  The specifications are
"source code" for the implementation...  doing the translation
("compiling?") is where security is handled.   This is very strong
security, because a compiler completely controls everything in the
implementation...

>  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.

PID=process id (a unique number assigned to each task)
UID=user id, the owner of the process

I think you meant processes can change UID.

In TUNES you can control the access to any thread at a very fine grain. 
(and using any program to determine the access restriction)  You don't
have to lump priviledges together like in UNIX. 

Communicating with untrusted systems, well, can you give an example?  Data
can be verified once imported into the system...  

>  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.

I think the passing of priviledge around is like the Exo kernel and like
the Grail system recently posted.  Grail called it "local addressing" or
"relative addressing".  I agree it's not very secure.

David Manifold <dem@tunes.org>
This message is placed in the public domain.