[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Challenge: Find potential use cases for non-trivial confinement

From: Marcus Brinkmann
Subject: Re: Challenge: Find potential use cases for non-trivial confinement
Date: Mon, 01 May 2006 07:58:23 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Mon, 01 May 2006 01:29:54 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> > Ok, that was not clear.  The default libraries and services will make
> > sure that the user does only execute programs from the user's own
> > storage.
> This STILL doesn't address my example. I started the program, and I
> handed you a descriptor that allows you to send IPC to my program. The
> entire point is that I have *not* permitted you to instantiate it
> directly or control its storage -- even if we have a "naked" storage
> allocator.
> So the "naked allocator" restriction is not achieving the objective: the
> user (in this case the recipient of the IPC capability) *still* cannot
> examine the program they are executing.
> So next we must remove IPC, or if we do not, we should admit that this
> is an impossible objective and stop compromising the system architecture
> in order to achieve it.

Processes in general do not send random IPC to other processes.  There
is a narrow number of distinct cases where in my design processes send
IPC to other processes, and I can justify each of them for my purpose.
This is really not very different from EROS.  As a very short summary,
the list is: IPC to system services, IPC between cooperating processes
(coordinated by a common parent), and communication between different
users/groups.  The latter class is the only one that requires special
consideration.  In this case, the communication must be tracable to a
legitimizing user action.

The reason you think that this does not achieve the objective must be
that you have the wrong idea of what my objective is.  We also have a
different idea of what properties we want to protect and which
violations consitute a compromise.

I believe I could achieve all my functional objectives in the
EROS/Coyotos system structure, although some things are made harder by
it than I deem necessary (in particular issues related to
virtualization of services).  I can also achieve the same objectives
in a much simpler system which has less code and less mechanisms.  The
things that you can do in EROS but which you can not do in my system
are, at this point, simply not on my agenda.  On the other hand, my
system is much more protective of the user's freedom (to use, inspect,
alter and copy data in the user's storage), and fits better with
virtualization.  This is admittedtly because it throws away those
mechanisms which make virtualization hard.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]