[Top][All Lists]

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

Re: Channel sessions

From: Carl Fredrik Hammar
Subject: Re: Channel sessions
Date: Mon, 23 Jul 2007 20:13:26 +0200
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1.50 (gnu/linux)


<olafBuddenhagen@gmx.net> writes:
> Hi,
> On Sun, Jul 22, 2007 at 03:56:41PM +0200, Carl Fredrik Hammar wrote:
>> Having special channel classes (or perhaps some other type of modules)
>> for it seems like the right way to go.  But the problem that these
>> channels can live in several translators remain.
> OK, let's look at an example:
>                                            ,-----.         ,-----.   ,-----
>                                       ,--->| mod |-> ... ->| mod |-->| app1
> ----.   ,-----.         ,-----.   ,-----.  `-----'         `-----'   `-----
> dev |-->| mod |-> ... ->| mod |-->| tee |
> ----'   `-----'         `-----'   `-----'  ,-----.         ,-----.   ,-----
>                                       `--->| mod |-> ... ->| mod |-->| app2
>                                            `-----'         `-----'   `-----
>       ^                                  ^
>       |                                  |
> My feeling about this is that while all the modules behind the tee can
> be loaded into the respective application processes, the tee itself
> should run as a real translator -- in an own process. This one can in
> turn load all the modules before the tee.
> The reason why this makes sense is that libchannel is really just an
> (almost transparent) optimization: It serves the purpose of avoiding
> crossing multiple process boundaries unnecessarily, if several modules
> live in the same protection domain. But this is not always the case --
> sometimes we actually have multiple protection domains.
> The tee is one example: It is a shared resource used by multiple
> applications -- one of which could actually be malicious. (Maybe just
> buggy, but that doesn't matter for the purpose of security evaluation.)
> The tee must be protected from this malicious process, so that the other
> applications can't be harmed.
> Another example might be a module that filters some raw data, where for
> security reasons the application is only allowed to see the filtered
> data. Such a filter module would also have to reside in an own
> protection domain (i.e. translator process), even though in this case
> all the modules form just a straight chain.
> -antrik-

Ok, I see your point.  I was thinking that since copies of channels
already exists in different clients then protection boundaries were
already circumvented.  But that isn't the case since a channel is just
information how the client should access it's back-end.  The client
could just access the back-end directly.  If that is not the case, the
channel should not be exposed.  If the clients shared state, one of
could muck it up or retrieve private information.

Thanks for making this clear to me!

To handle sessions I think I will simply let the modules handle open
and close RPCs as well, which can be forwarded up the hierarchy.  This
should make it possible to implement all kinds of (de)multiplexing as

Forwarding sessions across process boundaries, e.g. file and device
modules, can be done through reopening the file or device on each

This still requires a bit more thinking.  I think I'll enumerate
various muxing and demuxing strategies and see if I can't figure out
exactly how they fit into all of this.


reply via email to

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