[cap-talk] gauntlet - one way IPC considered useless,
John C. McCabe-Dansted
gmatht at gmail.com
Fri Jan 13 00:33:46 EST 2006
On Friday 13 January 2006 08:52, Jed at Webstart wrote:
> At 08:51 PM 1/9/2006, John McCabe-Dansted wrote:
> >One common one-way communication mechanism is the POSIX pipe. E.g.
> > foo A | bar B
> While I agree the pipe mechanism is common, the only uses I know
> of it as one-way communication are one-way for convenience, not one-way
> out of any security or integrity necessity.
True, OTOH, filehandles are used in UNIX for speed reasons rather than for
their cap like properties.
If a piece of code claims it only requires unidirectional communication it may
well be useful to enforce that; typically a unidirectional communication
channel is only half as dangerous as a bidirectional one.
> >(Actually, one covert channel remains, bar can choose to close the
> >pipe after receiving N blocks, thus transmitting a one-off O(ln(N))
> >bit message back to foo)
> The above is not really so "covert" in that it doesn't depend on any
> shared resource banging or anything like that. In principle such
> a back channel can even be used across network connections
> with flow control.
> As far as "one-off" goes, naturally the above can be repeated as
> often as necessary. To transmit N bytes back channel (with
> cooperation), simple transmit N blocks of from 0-255 bytes (blocks?)
> through the channel and block after the value of the byte that
> needs to be transmitted. This can be done quite rapidly - partly
> because there was never any intent (that I know of) to make such
> a pipe truly "one-way".
Simply blocking should not matter unless foo has a clock, and bar cannot close
the pipe more than once, unless it is passed the pipe more than once; neither
foo nor bar get to choose how often the user runs "foo A | bar B".
Also closing the pipe could be a capability we do not give to bar. Many UNIX
applications, like grep should never need to close an incoming pipe.
Another example of unidirectional communication is listening to network
broadcasts. It make sense that one should be able to listen to certain
network broadcasts without being able to transmit. For example, say you are
watching a realtime video broadcast stream with a closed-source codec. It may
be nice to know that although it can read from the UDP socket, it cannot send
information out of your computer.
John C. McCabe-Dansted
More information about the cap-talk