Re: Channel sessions

[Carl Fredrik Hammar]

Hello,

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

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

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.

Regards,
  Fredrik