Re: [ANNOUNCE] Introducing Codezero

[olafBuddenhagen]

Hi,

On Sun, Nov 08, 2009 at 04:53:00AM +0100, Bas Wijnen wrote:
> On Wed, Nov 04, 2009 at 07:01:42AM +0100, address@hidden
> wrote:
> > On Tue, Jul 28, 2009 at 08:37:36AM +0200, Bas Wijnen wrote:

> > > For me, supporting encapsulation is extremely important.  It means
> > > that a user can start a program in a safe way.  Even if the
> > > program is malicious, and somewhere on the system is an other
> > > malicious program which would like to work together with it, it is
> > > impossible because they cannot talk.
> > 
> > This is nice in theory, but doesn't really work in practice, because
> > of covert channels. All you can really do is make it more tricky,
> > and limit the rate at which the malicious components can
> > communicate; but not prevent it entirely. This makes me question
> > whether it's even worthwhile to try building a system around this...
> > 
> > Note that I do believe in limiting what potentially malicious
> > programs can do in the first place. I'm just sceptical about trying
> > to prevent cooperation between potentially malicious programs.
> 
> Yes, I agree.  However, I'm not building a system around preventing
> this attack.  I'm building it around "doing what the user wants".
> This means that a program started by the user must not be compromised
> by some other program, even if that other program is malicious.  For
> this, encapsulation (of the malicious program) is required.

Of course... But that totally misses my point :-)

I was explicitely talking *only* about the fact that I don't believe
it's worthwhile to try preventing covert channels at any costs (as some
will be left in any case); and thus don't think the channels created by
the resource management approach in Viengoos are a real problem.

> In X, any client can hijack all events on the server, and effectively
> take over the X interface of any other client, which includes sniffing
> passwords.

Actually it's not possible anymore when using the (fairly recent) X
security infrastructure, which can (for example) apply selinux rules in
X.

Of course selinux is a pain... But that's a different story :-)

-antrik-