Bill Frantz | 6 Apr 2006 05:57
Favicon

Fwd: The underhanded C contest...

Not directly related to capability languages, but the issue of hiding
evil code from human verifiers exists for these languages too.

Cheers - Bill

====== Forwarded Message ======
Date: 4/5/06 1:27 PM
Received: 4/5/06 9:21 PM -0400
From: perry@... (Perry E. Metzger)
To: cryptography@...

Quoting from the web page:

  We hereby announce our second annual contest to write innocent-looking
  C code implementing malicious behavior. In many ways this is the exact
  opposite of the Obfuscated C Code Contest: in this contest you must
  write code that is as readable, clear, innocent and straightforward as
  possible, and yet it must fail to perform at its apparent function. To
  be more specific, it should do something subtly evil.

http://www.brainhz.com/underhanded/

--

-- 
Perry E. Metzger        perry@...

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@...
====== End Forwarded Message ======

(Continue reading)

Marc Stiegler | 15 Apr 2006 04:05

OCaml and Emily in a Walnut, first draft

In preparation for the upcoming HP Tech Report on Emily, I have drafted 
a document about OCaml and Emily specifically designed to help C++ and 
Java programmers make the transition. This document is unlike anything 
else about OCaml that now exists. It is designed to step an imperative 
programmer through the process of writing significant OCaml programs.

Those of you in this community who have functional programming 
backgrounds, beware. This tutorial will leave you foaming at the mouth, 
beating your hands against the wall. Choose a room with soft surfaces if 
you decide to read this. As an example of how serious I am, here is an 
example: the section on Lists and list processing is not only the 
shortest section, it is also the last section, an afterthought, almost 
an appendix. Readers of this document will be writing whole systems 
before they learn what a list is.

Find OCaml and Emily in a Walnut at

http://www.skyhunter.com/marcs/emilyWalnut.html

It is "unpublished" in the sense that it is not yet listed on my home 
page. I will "publish" it when I have the Emily development environment 
also posted (as a zip file), which is still going to take some work.

I will be particularly interested in hearing criticisms from folks with 
non-functional programming backgrounds. Is this document helpful or not? 
It may not be. OCaml really is very different. But this doc at least 
tries to be helpful, whereas, in my experience, most OCaml documents 
couldn't care less about the difficulties faced by a person from a C 
background.

(Continue reading)

Mark S. Miller | 16 Apr 2006 05:06

A dissertation on the rationale, philosophy, and goals of E and related systems

Apologies for the wide distribution, but elements of this dissertation are
germane to each of these lists. Feedback appreciated, but please reply to me
or on an appropriate list, rather than using "Reply all". The copyright notice
is interim, until I figure out what open license I want on this.

Robust Composition:
Towards a Unified Approach to Access Control and Concurrency Control

When separately written programs are composed so that they may cooperate, they
may instead destructively interfere in unanticipated ways. These hazards limit
the scale and functionality of the software systems we can successfully
compose. This dissertation presents a framework for enabling those
interactions between components needed for the cooperation we intend, while
minimizing the hazards of destructive interference.

Great progress on the composition problem has been made within the object
paradigm, chiefly in the context of sequential, single-machine programming
among benign components. We show how to extend this success to support robust
composition of concurrent and potentially malicious components distributed
over potentially malicious machines. We present E, a distributed, persistent,
secure programming language, and CapDesk, a virus-safe desktop built in E, as
embodiments of the techniques we explain.

My dissertation at Johns Hopkins University, found at
http://www.erights.org/talks/thesis/index.html

Advisor: Jonathan S. Shapiro.
Readers: Scott Smith, Yair Amir.

--

-- 
(Continue reading)

Mariano Montone | 17 Apr 2006 16:21
Picon
Gravatar

Re: Newbie question

The complexity above is because of abstracting the 'deliver several
messages' structure. Doing it inline would almost be like your example:

carRcvr <- __whenMoreResolved(def deliverer implements PassByCopy {
                                 to run(target) :void {
                                   if (Ref.isEventual(target)) {
                                     target <- \
                                       __whenMoreResolved(deliverer)
                                   } else {
                                     target.moveTo(2,3)
                                     target.moveTo(5,6)
                                     target.moveTo(7,3)
                                   }
                                 }
                               })

Sorry, I have one more question (at the moment :P).
What happens if I do this?:

carRcvr <- __whenMoreResolved(def deliverer implements PassByCopy {
                                 to run(target) :void {
                                   if (Ref.isEventual(target)) {
                                     target <- \
                                       __whenMoreResolved(deliverer)
                                   } else {
                                     while(true){}
                                   }
                               
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang
Kevin Reid | 17 Apr 2006 16:58

Re: Newbie question

On Apr 17, 2006, at 10:21, Mariano Montone wrote:

> Sorry, I have one more question (at the moment :P).
> What happens if I do this?:
>
> carRcvr <- __whenMoreResolved(def deliverer implements PassByCopy {
>                                  to run(target) :void {
>                                    if (Ref.isEventual(target)) {
>                                      target <- \
>                                        __whenMoreResolved(deliverer)
>                                    } else {
>                                      while(true){}
>                                    }
>                                  }
>                                })
>
> Am I blocking the car vat?

Yes.

> If that's true then I may program a malicious object.

Yes. Vats accepting mobile code objects are vulnerable to such denial- 
of-service attacks.

The semi-safe middle ground is accepting PassByCopy objects with  
already-known makers -- such as introducing a separate object to make  
the 'deliverer' in my example.
<http://www.eros-os.org/pipermail/e-lang/2006-March/011166.html>

Since these objects can only deliver a finite set of messages to  
already-known receivers, they cannot be used to create infinite  
loops, unless the vat has published its __loop object (which is used  
to implement 'while').

However, even if this particular problem is avoided, a vat can still  
be slowed by flooding it with expensive-to-process messages.

The general solution is to use intermediate vats between clients and  
vats running shared services. The intermediate vats can be killed by  
resource limits without disturbing other users of the service.

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>
Mariano Montone | 17 Apr 2006 18:14
Picon
Gravatar

Re: Newbie question

Kevin,
          I really appreciate a lot your answering all my questions!!

The E world gets very, very interesting so unfortunately for you new questions may arise :P

Thank you,
                Mariano

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang
Mark Miller | 19 Apr 2006 20:31
Picon
Gravatar

Discussion of "Robust Composition" on "Lambda the Ultimate"

http://lambda-the-ultimate.org/node/1414

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

    Cheers,
    --MarkM
Jed at Webstart | 19 Apr 2006 22:54

Re: Card game based on covert channels

At 10:51 AM 3/7/2006, 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.
>
>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
>other than bids and the playing of cards -- is normally considered 
>to be cheating.

I agree with what David Hopewood says.  I note, however, that using
a secret convention could still be "covert" while using an overt channel
(bidding).

However, in looking at the Wikipedia definition for "Covert Channel":

http://en.wikipedia.org/wiki/Covert_channel

I can see how this bridge example might be considered a "covert channel":

"All covert channels draw their bandwidth (information-carrying capacity) from
a legitimate channel, thus reducing the capacity of the latter; however, the
bandwidth drawn from the channel is often unused, anyway, and so the covert
channel may still be well hidden."

It doesn't seem to me that the sorts of "wall banging" covert channels that
have so often been discussed in these forums as a means of escaping
efforts at confinement fit this definition.  If I am one of many processes
running in a shared resource time sharing system and I try to communicate
bits to a collaborator by going into a tight loop for some time for 1s and
waiting idly for 0s, what legitimate channel am I drawing bandwidth from?

E.g. from the referenced "Timing Channels" description:

"Suitable coding schemes could get comparable signaling rates over many
different resource types, despite countermeasures by the OS: besides page
faulting, one could signal via CPU demand, segment activation, disk cache
loading, or other means."

I wonder if this Wikipedia definition of "covert channel" might need 
some tuning?

Is the above sort of communication by loading shared resources a
defining characteristic of the sort of "covert channel" that we often
discuss as a means to escape confinement?  Perhaps another term
is needed?  To me the wall banging example and the steganography
example are fundamentally different.  The steganography example does
draw bandwidth from a legitimate channel.  The wall banging (timing)
example I believe does not.

This seems to me a potential source of confusion.  What do others think?

--Jed http://www.webstart.com/jed/ 
Kevin Reid | 21 Apr 2006 19:17

Thought: Classification of Miranda methods

Object-specific
   __printOn/1
   __respondsTo/2
   __getAllegedType/0

Object-referencing
   __conformTo/1
   __order/2
   __whenMoreResolved/1
   __getPropertySlot/1

Independent
   __optUncall/0
   __whenBroken/1
   __reactToLostClient/1

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>
Kevin Reid | 27 Apr 2006 01:11

Thought: DeepFrozen too restrictive for guards?

The plan has been to require that all objects in guard positions are  
DeepFrozen.

It occurred to me that there might be reasons to use a less  
restrictive condition. For example:

   def deopt { to get(default) { def guard { to coerce(specimen, _) {
     return if (specimen == null) {specimen} else {default} }}}}

   def ...(..., log :deopt[stdout]) {
   }

would be rejected since stdout isn't DeepFrozen.

Similarly, the new guard-based expansions in 0.8.36f use non- 
DeepFrozen guard construction:

   ? epatt```$$stdout```
   # value: epatt`[] :__MatchBind.get(simple__quasiParser.matchMaker 
("${0}"), __makeList.run(stdout))`

Possible solutions:

1. Rather than the whole guard being required DeepFrozen, 'deopt' is.

    Problems: makes guard expressions have strange semantics, as it's  
not a simple composition with CallExpr any more.

2. Guards may hold non-DeepFrozen references as long as they do not  
interact with them.

    Problems: hard to define right. Doesn't work at all for the quasi- 
pattern case.

3a. Introduce the guard-but-not-DeepFrozen operator (which I've  
mentioned before, though possibly not on e-lang).

     It would be identical to the : pattern but with a different  
symbol, and possibly using 'run' or 'match' instead of  
'coerce' (since these Are Not Guards Since They Aren't DeepFrozen).

     Problems: Hard to find a good syntax for it.

3b. Same as 3a, but guard patterns expand to it. This simplifies  
Kernel-E.

     Problems: Doesn't apply to result-guard positions. Would make  
expansions uglier by mentioning DeepFrozen (or Guard) everywhere.

(Irrelevantly, we need to kill the 'ValueGuard' name, since  
SlotGuards don't exist any more.)

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>

Gmane