Laurent Martelli
01 Jan 1999 07:47:51 +0100

>>>>> "Tril" == Tril  <> writes:

    Tril> On 29 Dec 1998, Laurent Martelli wrote:

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

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

    Tril> I think you meant processes can change UID.


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

Well, I think that threads or processes are just an implementation
trick to give the impression that you have parallel execution. But I
don't consider them as a good high level abstraction. 

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

I was referning to the fact that you can execute some code which you
don't know exactly what it does (cf applets). It is executed with your
rights, and can therefore mess with private data. In fact, this is
rather a problem of trust. 

One possible way of handling this without having to look at the code,
would be to use post conditions. They are supposed to describe what
the code do, so if we can check that the post condition is verified,
we know that the code is correct. But there's however a problem : how
can you be sure that the code does not do more than what it is
supposed to do?