Kevin Reid | 1 Mar 04:58 2006
Picon

__reactToLostClient and distributed confinement

Has the effect of the information provided by __reactToLostClient's  
parameter on distributed confinement been considered?

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>
Mark S. Miller | 1 Mar 08:48 2006

Re: __reactToLostClient and distributed confinement

Kevin Reid wrote:
> Has the effect of the information provided by __reactToLostClient's  
> parameter on distributed confinement been considered?

No. What problem do you anticipate?

--

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM
Constantine Plotnikov | 1 Mar 14:05 2006

Re: Re: [e-lang] Introducing Emily, "...capabilities are useless too..."

Jed at Webstart wrote:
>
>> If task is not solvable in general, it does not means that it cannot 
>> be solved in some particular case. And if we are solving the problem 
>> in particular case, it is better have some foundation problems like 
>> capability confinement and exception data leaks solved.
>>
> #2.  I won't explicitly address the above means to prevent covert 
> channels except to say that given the history of analysis of covert 
> channels I'm somewhat skeptical of such efforts. 
There are scenarios in which it is possible to make a cost of covert 
channels very high. Lets say we have some analytical program that 
evaluate some tradeable item and gives one of three results:
- item is suitable
- item is not suitable
- item evaluation failed.

If we want to allow one party to run this program, but we do not want 
that program to leak data to the originating party. We could do the 
following:
1. Install program on computer disconnected from network in a 
electromagnetically-and-sound-shielded bunker, use fully charged cell as 
power source.
2. Run the program. If charged cell is fully used before calculation is 
completed or if some fixed timeout passes, consider result to be "item 
evaluation failed".
3. Write the result on piece of paper.
5. Send result by email on next day morning.
6. Discharge cell completely and start charging it on the next day. Also 
a good idea is to destroy computer afterwards just in case ;).
(Continue reading)

Kevin Reid | 1 Mar 14:42 2006
Picon

Re: __reactToLostClient and distributed confinement

On Mar 1, 2006, at 2:48, Mark S. Miller wrote:
> Kevin Reid wrote:
>> Has the effect of the information provided by  
>> __reactToLostClient's  parameter on distributed confinement been  
>> considered?
>
> No. What problem do you anticipate?

I'm not sure. I once noticed that it supplies information that is not  
explicitly passed by the object's 'normal' clients, and so I wonder  
whether it reveals something.

I now suspect that this isn't a problem for distributed confinement,  
as in that case information is already leaked in by the /timing/ - or  
just occurrence - of deaths of vats making up the box. But are there  
any other situations?

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>
Constantine Plotnikov | 1 Mar 15:02 2006

Card game based on covert channels

I have just remembered that there is a card game that is based on covert 
channels. Tt is "Contract Bridge". Covert channel is established and 
used in bidding process. There is also a way to introduce a noise in the 
channel to confuse opponents covert channel.

http://en.wikipedia.org/wiki/Contract_bridge#Bidding_systems_and_conventions

This game might be a good sample to explain what is a covert channel in 
the protocol in security books or articles.

Constantine
Chris Hibbert | 1 Mar 18:21 2006

Re: Card game based on covert channels

> I have just remembered that there is a card game that is based on
> covert channels. Tt is "Contract Bridge". Covert channel is
> established and used in bidding process. There is also a way to
> introduce a noise in the channel to confuse opponents covert channel.
> 
> This game might be a good sample to explain what is a covert channel
> in the protocol in security books or articles.

That's an interesting idea, but the fact that the bidders are required 
to explain their (partners') bids makes it more overt than covert.  I 
think it may make a good opening example, but if you try to explain it 
in any depth, the analogy will get pretty strained.

And most bidding systems discourage injecting noise into the opponents' 
channel, since your partner is expected to decode that as a signal to her.

Chris
--

-- 
Currently reading: David Buller: Adapting Minds;
    Patrick W. Rice, IRA Wealth: Strategies for Real Estate
    Investment; Ken MacLeod, Learning the World

Chris Hibbert
hibbert@...
Blog:   http://pancrit.org
Constantine Plotnikov | 1 Mar 19:15 2006

Re: Card game based on covert channels

Chris Hibbert wrote:

>> I have just remembered that there is a card game that is based on
>> covert channels. Tt is "Contract Bridge". Covert channel is
>> established and used in bidding process. There is also a way to
>> introduce a noise in the channel to confuse opponents covert channel.
>>
>> This game might be a good sample to explain what is a covert channel
>> in the protocol in security books or articles.
>
>
> That's an interesting idea, but the fact that the bidders are required 
> to explain their (partners') bids makes it more overt than covert.  I 
> think it may make a good opening example, but if you try to explain it 
> in any depth, the analogy will get pretty strained.

This is a covert channel because the formal surface meaning of the 
protocol is making bids. But partners interpreting it as information 
about state of their hands. I have not played game myself, so it is 
interesting to learn that there are even rules for using bids as covert 
channel ;).

>
> And most bidding systems discourage injecting noise into the 
> opponents' channel, since your partner is expected to decode that as a 
> signal to her.
>
I had a friend that played the game quite much and he told me that some 
bid values are often reserved in the protocol to make empty shots that 
answers using standard systems more difficult if usage of standard 
(Continue reading)

David Hopwood | 7 Mar 18:51 2006
Picon

Re: Card game based on covert channels

Constantine Plotnikov wrote:
> Chris Hibbert wrote:
> 
>>> I have just remembered that there is a card game that is based on
>>> covert channels. It is "Contract Bridge". Covert channel is
>>> established and used in bidding process. There is also a way to
>>> introduce a noise in the channel to confuse opponents covert channel.
>>>
>>> This game might be a good sample to explain what is a covert channel
>>> in the protocol in security books or articles.
>>
>> That's an interesting idea, but the fact that the bidders are required
>> to explain their (partners') bids makes it more overt than covert.  I
>> think it may make a good opening example, but if you try to explain it
>> in any depth, the analogy will get pretty strained.
> 
> This is a covert channel because the formal surface meaning of the
> protocol is making bids. But partners interpreting it as information
> about state of their hands.

I disagree that this is a good example; bidding is an overt channel.

As the Wikipedia article correctly says:

    * Information may only be passed by the calls made and later by the cards
      played, and not by any other means.
    * The agreed-upon *meaning* [emphasis added] of all information passed
      must be available to the opponents.

Use of covert channels in Contract Bridge -- that is, communication channels
(Continue reading)

Constantine Plotnikov | 7 Mar 22:56 2006

Re: Card game based on covert channels

David Hopwood wrote:

>Constantine Plotnikov wrote:
>  
>
>>Chris Hibbert wrote:
>>
>>    
>>
>>>>I have just remembered that there is a card game that is based on
>>>>covert channels. It is "Contract Bridge". Covert channel is
>>>>established and used in bidding process. There is also a way to
>>>>introduce a noise in the channel to confuse opponents covert channel.
>>>>
>>>>This game might be a good sample to explain what is a covert channel
>>>>in the protocol in security books or articles.
>>>>        
>>>>
>>>That's an interesting idea, but the fact that the bidders are required
>>>to explain their (partners') bids makes it more overt than covert.  I
>>>think it may make a good opening example, but if you try to explain it
>>>in any depth, the analogy will get pretty strained.
>>>      
>>>
>>This is a covert channel because the formal surface meaning of the
>>protocol is making bids. But partners interpreting it as information
>>about state of their hands.
>>    
>>
>
(Continue reading)

Kevin Reid | 11 Mar 04:11 2006
Picon

Bug (0.8.35f): Scope oddities in ObjectExpr with 'extends'; Kernel-E change proposal

   ? e`def a {}`.staticScope()
   # value: <[] := [] =~ ["a"] + var []>

   ? e`def a extends def b {}`.staticScope()
   # syntax error: Unexpected EOF

   ? e`def a extends (def b := 1) {}`.staticScope()
   # value: <[] := ["E"] =~ ["a"] + var []>

'b' is not visible outside.

   ? e`def a implements (def b := 1) {}`.staticScope()
   # value: <[] := [] =~ ["b", "a"] + var []>

'b' is visible outside.

   ? e`def a extends (def b := 1) implements (def c := 2) {} 
`.staticScope()
   # value: <[] := ["E"] =~ ["a"] + var []>

The presence of an 'extends' clause causes the 'implements'  
expression to not be visible outside.

I think this could be fixed by a minor contortion of the ObjectExpr  
expansion:

def a := {
     def super := def b := 1
     def "$a__C" implements (def c := 2) {
         match pair__1 {
(Continue reading)


Gmane