modred team mailing list archive

[Scott Lawrence <bytbox@xxxxxxxxx>]

Ok.  We'll use this if necessary then.  I hope to be able to get
ptrace to work though, which renders this redundant.

On 12/29/09, Michael Cohen <gnurdux@xxxxxxxxx> wrote:
> No, NaCl doesn't use system calls; that's why the same code works on
> Windows and Linux.  You have to compile your program with the NaCl
> compiler, which links it with NaCl libraries.  You can, however, modify
> or add your own "system calls" that the NaCl program can use (I did this
> today to disable threading in a version to be used for the Game
> Contest).  The one slight annoyance with NaCl is that it may not have
> quite the same semantics in all calls that people are used to, and it
> might be missing some obscure features of glibc, since it uses a smaller
> C library, newlib, instead.  The C++ libraries work fine with newlib.  I
> doubt that will be an issue for us, though.  Also, someone ported glibc
> to NaCl and apparently was even able to run Python with it.
>
> Michael Cohen
>
> Scott Lawrence wrote:
>> This looks good.  Does NaCl allow us to actually intercept and replace
>> system calls? How much flexibility do we have?
>>
>> On 12/29/09, Michael Cohen <gnurdux@xxxxxxxxx> wrote:
>>> The original paper describing Google Native Client claims a less than 5%
>>> performance hit on average for such intensive tasks as the chess engine
>>> crafty and an H.264 decoder.  The code size does increase substantially,
>>> sometimes by up to 50%, but that is no biggie.
>>>
>>> Michael Cohen
>>>
>>> Michael Cohen wrote:
>>>> SDL is the cross-platform graphics/sound library that NaCl (and many
>>>> other cross-platform graphical programs) uses.  Terminal based programs
>>>> don't use it.  I will look for benchmarks sometime today; I think there
>>>> are some that come with NaCl.
>>>>
>>>> Michael Cohen
>>>>
>>>> Scott Lawrence wrote:
>>>>> What exactly is SDL, and why would any terminal-based programs use it?
>>>>>
>>>>> Can you get us trustworthy benchmarks?
>>>>>
>>>>>
>>>>> On 12/29/09, Michael Cohen <gnurdux@xxxxxxxxx> wrote:
>>>>>> NaCl seems to be working as a sandbox.  The only thing that you need
>>>>>> to
>>>>>> do that is strange with it is compile with sdl=none (this disables
>>>>>> SDL)
>>>>>> so that the programs can't make graphical windows pop up.
>>>>>>
>>>>>> Michael Cohen
>>>>>>
>>>>>> Scott Lawrence wrote:
>>>>>>> Great.  Just make sure it doesn't come with a performance hit.
>>>>>>>
>>>>>>> On 12/29/09, Michael Cohen <gnurdux@xxxxxxxxx> wrote:
>>>>>>>> So I *think* we might be able to make a cross-platform sandbox.
>>>>>>>> Well,
>>>>>>>> make is not quite the write word.  "Use".  Google's Native Client is
>>>>>>>> designed to make safe, cross-platform native code for use as a
>>>>>>>> browser
>>>>>>>> plugin, but apparently the sandboxy part is available separately.
>>>>>>>> If we
>>>>>>>> can get this working, this would let the client send the *same
>>>>>>>> native
>>>>>>>> code* to the Windows and Linux clients, and have them *both*
>>>>>>>> execute it
>>>>>>>> safely (since it uses system-call-free code).  I am checking out the
>>>>>>>> source now.
>>>>>>>>
>>>>>>>> Michael Cohen
>>>>>>>>
>>>>>>>> Scott Lawrence wrote:
>>>>>>>>> Short answer: no.
>>>>>>>>>
>>>>>>>>> Long answer: We're not writing a C sandbox that works on
>>>>>>>>> windows/non-unix.  That's the only restriction.  Windows people can
>>>>>>>>> run the java, perl, python, and whatever other clients we write.
>>>>>>>>> Furthermore, they can submit code with a C client, but there
>>>>>>>>> better be
>>>>>>>>> a java client to run code to give them CPU time credits (provided
>>>>>>>>> that
>>>>>>>>> the cluster they're using has that feature enabled).
>>>>>>>>>
>>>>>>>>> On 12/28/09, Frederic Koehler <fkfire@xxxxxxxxx> wrote:
>>>>>>>>>> Um...Are we going to require that all clients run linux?
>>>>>>>>>>
>>>>>>>>>> On Mon, Dec 28, 2009 at 11:08 PM, Michael Cohen
>>>>>>>>>> <gnurdux@xxxxxxxxx>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> ptrace tells you whenever the process tried to make a system
>>>>>>>>>>> call.
>>>>>>>>>>> You
>>>>>>>>>>> can
>>>>>>>>>>> then do whatever you want with that information, including
>>>>>>>>>>> recording
>>>>>>>>>>> it
>>>>>>>>>>> and
>>>>>>>>>>> passing it on to the kernel or doing your own action.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Michael Cohen
>>>>>>>>>>>
>>>>>>>>>>> Scott Lawrence wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Actually, not.  Ignore that last message.
>>>>>>>>>>>>
>>>>>>>>>>>> Can you build a prototype, that calls a specified function in
>>>>>>>>>>>> place
>>>>>>>>>>>> of
>>>>>>>>>>>> the kernel??
>>>>>>>>>>>>
>>>>>>>>>>>> On 12/28/09, Scott Lawrence <bytbox@xxxxxxxxx> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Ok.  I think that for the most part, we should block system
>>>>>>>>>>>>> calls.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/28/09, Michael Cohen <gnurdux@xxxxxxxxx> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Very little to not at all if the code doesn't make many system
>>>>>>>>>>>>>> calls.
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>> wouldn't expect it to make many anyway; the tasks that this
>>>>>>>>>>>>>> is good
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> shouldn't be ones that require much communication (because the
>>>>>>>>>>>>>> Internet
>>>>>>>>>>>>>> is fairly slow; if it's always sending stuff and requiring
>>>>>>>>>>>>>> responses
>>>>>>>>>>>>>> that gives probably a .1 second latency each step at least),
>>>>>>>>>>>>>> so its
>>>>>>>>>>>>>> mostly just running on the CPU.  It would certainly add less
>>>>>>>>>>>>>> overhead
>>>>>>>>>>>>>> for CPU-intensive things than say, Java.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Michael Cohen
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Scott Lawrence wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And this is the only thing that needs to be done? How much
>>>>>>>>>>>>>>> will it
>>>>>>>>>>>>>>> slow the code down? More importantly
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 12/28/09, Michael Cohen <gnurdux@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We can't actually block interrupts; that require kernel mode
>>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>> Also, I think there are other mechanisms for system calls.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> BUT
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> lucky for us, Linux (and other unixes, but with slightly
>>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>>> implementations) has a built-in way to intercept system
>>>>>>>>>>>>>>>> calls.
>>>>>>>>>>>>>>>> It's
>>>>>>>>>>>>>>>> called ptrace, and it is what is used for the USACO sandbox.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Michael Cohen
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Scott Lawrence wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Oh. I see.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> My first instinct is to say: "ban them!"  But it would be
>>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>>> nice
>>>>>>>>>>>>>>>>> if most existing source code could run out-of-the-box on
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> cluster,
>>>>>>>>>>>>>>>>> even if there wouldn't be a speedup.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm not planning on support C/C++ on windows - that's way
>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>> trouble - so we only have to worry about unix systems.  Are
>>>>>>>>>>>>>>>>> interrupts
>>>>>>>>>>>>>>>>> the only things we would have to block?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 12/28/09, Michael Cohen <gnurdux@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You are simply incorrect here.  The issue isn't library
>>>>>>>>>>>>>>>>>> calls,
>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>> system calls.  Libc calls themselves use system calls,
>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> interrupts.  You can do everything without touching
>>>>>>>>>>>>>>>>>> libc.  You
>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>> the right stuff to the stuck and do an interrupt or
>>>>>>>>>>>>>>>>>> whatever.
>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>> library doesn't have some special way to access the
>>>>>>>>>>>>>>>>>> kernel.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Michael Cohen
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Scott Lawrence wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You're all missing the point.  I'm claiming that,
>>>>>>>>>>>>>>>>>>> properly
>>>>>>>>>>>>>>>>>>> implemented, Modred should require no sandboxing outside
>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> necessary to implement it's logic.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So back to our good friends Alice, Bob, and Mallory.
>>>>>>>>>>>>>>>>>>> Alice
>>>>>>>>>>>>>>>>>>> sends
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> cluster (which means she directs it to the hub, but
>>>>>>>>>>>>>>>>>>> let's just
>>>>>>>>>>>>>>>>>>> consider the cluster a big black box for now) some C
>>>>>>>>>>>>>>>>>>> source
>>>>>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>>>>> This code does some strange stuff - lots of file i/o and
>>>>>>>>>>>>>>>>>>> memory
>>>>>>>>>>>>>>>>>>> access.  What does the cluster do with this?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It links the program with its own special libraries.
>>>>>>>>>>>>>>>>>>> Even
>>>>>>>>>>>>>>>>>>> inline
>>>>>>>>>>>>>>>>>>> assembly has to call functions to interface with the hard
>>>>>>>>>>>>>>>>>>> drive
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> allocate memory and such. Malicious code that gets
>>>>>>>>>>>>>>>>>>> submitted
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> server will be sanitized in this fashion.  The only
>>>>>>>>>>>>>>>>>>> problem I
>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> with illegal memory access - but I suspect this will be
>>>>>>>>>>>>>>>>>>> dealt
>>>>>>>>>>>>>>>>>>> with,
>>>>>>>>>>>>>>>>>>> because the cluster has to analyze what data the client
>>>>>>>>>>>>>>>>>>> program
>>>>>>>>>>>>>>>>>>> accesses anyway...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Now Bob wants to compile and link his program on his own
>>>>>>>>>>>>>>>>>>> computer.
>>>>>>>>>>>>>>>>>>> Fine.  He uses a different (smaller, incidentally) set of
>>>>>>>>>>>>>>>>>>> libraries.
>>>>>>>>>>>>>>>>>>> These libraries don't intercept every call of malloc and
>>>>>>>>>>>>>>>>>>> stuff
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>> are run on his computer.  But if he wants to access
>>>>>>>>>>>>>>>>>>> cluster
>>>>>>>>>>>>>>>>>>> data,
>>>>>>>>>>>>>>>>>>> he
>>>>>>>>>>>>>>>>>>> has to use special functions.  And he can't actually run
>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> cluster.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Now what does Mallory do again?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 12/28/09, Michael Cohen <gnurdux@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Server-side I don't see an issue.  (java's, lua's,
>>>>>>>>>>>>>>>>>>>>  >  javascript's, .NET/mono, some other random thing) is
>>>>>>>>>>>>>>>>>>>> basically
>>>>>>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>>>>>> I already said.  There are other sandboxing systems
>>>>>>>>>>>>>>>>>>>> that are
>>>>>>>>>>>>>>>>>>>> designed
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> work on x86 native code, such as vx32 (I think I
>>>>>>>>>>>>>>>>>>>> mentioned
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> also).
>>>>>>>>>>>>>>>>>>>> Many of these schemes (with the exception of vx32) have
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> advantage
>>>>>>>>>>>>>>>>>>>> that they also automatically make the code
>>>>>>>>>>>>>>>>>>>> cross-platform.
>>>>>>>>>>>>>>>>>>>> Even
>>>>>>>>>>>>>>>>>>>> vx32
>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>> supposedly portable to Windows, but nobody has done it
>>>>>>>>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>> no
>>>>>>>>>>>>>>>>>>>> idea if any of us have the expertise to.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Frederic Koehler wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> As far as sandboxing, server-side you can presumably
>>>>>>>>>>>>>>>>>>>>> rely on
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> operating
>>>>>>>>>>>>>>>>>>>>> system's sandboxes (per-user or perhaps some more
>>>>>>>>>>>>>>>>>>>>> elaborate
>>>>>>>>>>>>>>>>>>>>> mechanism
>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>> FreeBSD's jails).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But as soon as the cluster sends code out to clients,
>>>>>>>>>>>>>>>>>>>>> obviously
>>>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>> big issue if we let them do whatever the hell they
>>>>>>>>>>>>>>>>>>>>> want.
>>>>>>>>>>>>>>>>>>>>> Just
>>>>>>>>>>>>>>>>>>>>> preventing
>>>>>>>>>>>>>>>>>>>>> assembly or anything like that simply doesn't work in
>>>>>>>>>>>>>>>>>>>>> C/C++,
>>>>>>>>>>>>>>>>>>>>> (not
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> mention
>>>>>>>>>>>>>>>>>>>>> it would be suprisingly hard/irritating,) since the
>>>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>>> the system-calls (you could try not linking against
>>>>>>>>>>>>>>>>>>>>> libc,too,
>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>> _really_ have no portability :P).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> System-call controlling is possible, but is either
>>>>>>>>>>>>>>>>>>>>> pretty
>>>>>>>>>>>>>>>>>>>>> unportable
>>>>>>>>>>>>>>>>>>>>> (lots
>>>>>>>>>>>>>>>>>>>>> of x86 assembly stuff) or slow-ish (virtual machines).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> That being said, if you completely seperate
>>>>>>>>>>>>>>>>>>>>> client-sendable
>>>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>>> server-code, I think that allays a lot of the concerns.
>>>>>>>>>>>>>>>>>>>>> Requiring
>>>>>>>>>>>>>>>>>>>>> client-sendable code to be written for some safe VM
>>>>>>>>>>>>>>>>>>>>> (java's,
>>>>>>>>>>>>>>>>>>>>> lua's,
>>>>>>>>>>>>>>>>>>>>>  javascript's, .NET/mono, some other random thing)
>>>>>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>>> avoid
>>>>>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>>>> In
>>>>>>>>>>>>>>>>>>>>> addition, client-sendable code would intentionally be
>>>>>>>>>>>>>>>>>>>>> written
>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> knowledge
>>>>>>>>>>>>>>>>>>>>> of the sensitivity of the data it handles (i.e. not
>>>>>>>>>>>>>>>>>>>>> written
>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> data is important).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 28, 2009 at 7:49 PM, Michael Cohen <
>>>>>>>>>>>>>>>>>>>>> gnurdux@xxxxxxxxx>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>  I would still be happier if there were a sandbox,
>>>>>>>>>>>>>>>>>>>>> actually.
>>>>>>>>>>>>>>>>>>>>>> There
>>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>> ways
>>>>>>>>>>>>>>>>>>>>>> of getting around that sort of thing that are too
>>>>>>>>>>>>>>>>>>>>>> complicated
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> prevent
>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>> the source level IMO.  For instance, you can use
>>>>>>>>>>>>>>>>>>>>>> inline
>>>>>>>>>>>>>>>>>>>>>> assembly.
>>>>>>>>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>> block inline assembly.  That's all well and good, but
>>>>>>>>>>>>>>>>>>>>>> now
>>>>>>>>>>>>>>>>>>>>>> we've
>>>>>>>>>>>>>>>>>>>>>> blocked
>>>>>>>>>>>>>>>>>>>>>> people using legitimate assembly optimizations.
>>>>>>>>>>>>>>>>>>>>>> Worse, what
>>>>>>>>>>>>>>>>>>>>>> happens
>>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>>> execute some shellcody stuff, allowing them to
>>>>>>>>>>>>>>>>>>>>>> escape?  I
>>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>>>>> how to block that at all.  On the other hand, a
>>>>>>>>>>>>>>>>>>>>>> sandbox
>>>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>> add
>>>>>>>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>>>>>>> overhead since these tasks will most likely use lots
>>>>>>>>>>>>>>>>>>>>>> of CPU
>>>>>>>>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>>> few
>>>>>>>>>>>>>>>>>>>>>> system calls or whatever.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Michael Cohen
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Scott Lawrence wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  Ok, I'm going to build a prototype of my privacy
>>>>>>>>>>>>>>>>>>>>>> model.
>>>>>>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>>>>>>> to implement the challenge-response stuff, I'll
>>>>>>>>>>>>>>>>>>>>>>> assume
>>>>>>>>>>>>>>>>>>>>>>> there's
>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>> implementation of that and that it works.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I think I've isolated the misunderstanding about the
>>>>>>>>>>>>>>>>>>>>>>> sandboxes.
>>>>>>>>>>>>>>>>>>>>>>> You
>>>>>>>>>>>>>>>>>>>>>>> don't submit binary code the the Modred cluster - you
>>>>>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>>>>>> submit
>>>>>>>>>>>>>>>>>>>>>>> source, to be linked by the modred cluster with the
>>>>>>>>>>>>>>>>>>>>>>> relevant
>>>>>>>>>>>>>>>>>>>>>>> libraries, or you link the code yourself with the
>>>>>>>>>>>>>>>>>>>>>>> libraries.
>>>>>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>>>>> libraries that you would link with merely copy the
>>>>>>>>>>>>>>>>>>>>>>> program
>>>>>>>>>>>>>>>>>>>>>>> over
>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> cluster, where it can be executed in a manner deemed
>>>>>>>>>>>>>>>>>>>>>>> fit
>>>>>>>>>>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>>> there.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I suppose you could say that that is a sandbox. ;-)
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 12/28/09, Michael Cohen <gnurdux@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>  If you read my email more carefully, you will see
>>>>>>>>>>>>>>>>>>>>>>> that I
>>>>>>>>>>>>>>>>>>>>>>> am
>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>> necessary objecting to Scott's suggestion.  I say
>>>>>>>>>>>>>>>>>>>>>>>> that it
>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>> necessary, but that it would be the only thing
>>>>>>>>>>>>>>>>>>>>>>>> necessary
>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> allow
>>>>>>>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>>>>>> problem-specific privacy tasks to be used.  The
>>>>>>>>>>>>>>>>>>>>>>>> need for
>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>> sandbox
>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>> pretty simple.  If we make untrusted users able to
>>>>>>>>>>>>>>>>>>>>>>>> ask
>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>> tasks,
>>>>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>>>> they upload code, then I don't want it running
>>>>>>>>>>>>>>>>>>>>>>>> unsandboxed
>>>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>>>>>>> computer.  Otherwise, their code could steal my
>>>>>>>>>>>>>>>>>>>>>>>> files,
>>>>>>>>>>>>>>>>>>>>>>>> wipe
>>>>>>>>>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>>>>>>> harddisk,
>>>>>>>>>>>>>>>>>>>>>>>> install Windows or do other undesirable things.  If
>>>>>>>>>>>>>>>>>>>>>>>> it is
>>>>>>>>>>>>>>>>>>>>>>>> sandboxed,
>>>>>>>>>>>>>>>>>>>>>>>> then arbitary code can be executed safely, as long
>>>>>>>>>>>>>>>>>>>>>>>> as we
>>>>>>>>>>>>>>>>>>>>>>>> trust
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> sandbox.  Sandboxed environments are often also
>>>>>>>>>>>>>>>>>>>>>>>> cross-platform,
>>>>>>>>>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>>>>>>>> plus, since they typically replace or intercept any
>>>>>>>>>>>>>>>>>>>>>>>> kind
>>>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>>>>>>>>>> call.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Michael Cohen
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Scott Lawrence wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>  Well, I'm glad someone expresses opinions I don't
>>>>>>>>>>>>>>>>>>>>>>>> agree
>>>>>>>>>>>>>>>>>>>>>>>>> with...
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I think Mikey's objection to privacy concerns is
>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>>>>>>>> problem-specific, we can't reasonably expect to
>>>>>>>>>>>>>>>>>>>>>>>>> have a
>>>>>>>>>>>>>>>>>>>>>>>>> general
>>>>>>>>>>>>>>>>>>>>>>>>> implementation.  But if the user specifies which
>>>>>>>>>>>>>>>>>>>>>>>>> parts
>>>>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> data
>>>>>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>>>> private, the Modred hub just has to be sure to
>>>>>>>>>>>>>>>>>>>>>>>>> divvy up
>>>>>>>>>>>>>>>>>>>>>>>>> tasks
>>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>>>>>>>>>>>> that gives those bits of information only to the
>>>>>>>>>>>>>>>>>>>>>>>>> trusted,
>>>>>>>>>>>>>>>>>>>>>>>>> dedicated
>>>>>>>>>>>>>>>>>>>>>>>>> servers.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> For the purposes of clarity, I will be referring to
>>>>>>>>>>>>>>>>>>>>>>>>> dedicated
>>>>>>>>>>>>>>>>>>>>>>>>> servers
>>>>>>>>>>>>>>>>>>>>>>>>> as simply "servers", and the central server as the
>>>>>>>>>>>>>>>>>>>>>>>>> "hub".
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I don't see the need for a sandbox.  Could you
>>>>>>>>>>>>>>>>>>>>>>>>> present
>>>>>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>>>>>>>>>>>> attacks that a sandbox would fix?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 12/28/09, Michael Cohen <gnurdux@xxxxxxxxx>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>  It seems to me that dealing with privacy concerns
>>>>>>>>>>>>>>>>>>>>>>>>> is an
>>>>>>>>>>>>>>>>>>>>>>>>>> extremely
>>>>>>>>>>>>>>>>>>>>>>>>>> problem-specific issue.  In any given case you
>>>>>>>>>>>>>>>>>>>>>>>>>> need to
>>>>>>>>>>>>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>>>>>>>>>>>> how
>>>>>>>>>>>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>>>>>>>>>>> you can give to people without letting private
>>>>>>>>>>>>>>>>>>>>>>>>>> information
>>>>>>>>>>>>>>>>>>>>>>>>>> leak,
>>>>>>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> details vary greatly from problem to problem.
>>>>>>>>>>>>>>>>>>>>>>>>>> That
>>>>>>>>>>>>>>>>>>>>>>>>>> isn't
>>>>>>>>>>>>>>>>>>>>>>>>>> our
>>>>>>>>>>>>>>>>>>>>>>>>>> business,
>>>>>>>>>>>>>>>>>>>>>>>>>> and I don't think we should concern ourselves
>>>>>>>>>>>>>>>>>>>>>>>>>> with it
>>>>>>>>>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>>>>>>>>> much.
>>>>>>>>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>>>>>>>>>>>>> I see it there are two options:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 1. make this designed for stuff without privacy
>>>>>>>>>>>>>>>>>>>>>>>>>> concerns
>>>>>>>>>>>>>>>>>>>>>>>>>>       I think this is both the easiest and the
>>>>>>>>>>>>>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>>>>>>>>>>>>> option.
>>>>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>>>>>>>>>>>> like the idea of a public, free service doing
>>>>>>>>>>>>>>>>>>>>>>>>>> computations
>>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>> evil
>>>>>>>>>>>>>>>>>>>>>>>>>> corporation anyway; if it's being done BY the
>>>>>>>>>>>>>>>>>>>>>>>>>> public it
>>>>>>>>>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>> done
>>>>>>>>>>>>>>>>>>>>>>>>>> FOR the public.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 2. add in a small amount of functionality
>>>>>>>>>>>>>>>>>>>>>>>>>> designed to
>>>>>>>>>>>>>>>>>>>>>>>>>> facilitate
>>>>>>>>>>>>>>>>>>>>>>>>>> dealing
>>>>>>>>>>>>>>>>>>>>>>>>>> with privacy concerns
>>>>>>>>>>>>>>>>>>>>>>>>>>       At the level of this project, that would
>>>>>>>>>>>>>>>>>>>>>>>>>> probably
>>>>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> controls
>>>>>>>>>>>>>>>>>>>>>>>>>> on what data gets sent to what people.  There
>>>>>>>>>>>>>>>>>>>>>>>>>> might be
>>>>>>>>>>>>>>>>>>>>>>>>>> reasons
>>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>> adding such controls anyway; some tasks could be
>>>>>>>>>>>>>>>>>>>>>>>>>> designated
>>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>>>>>>>>> "trusted" users.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Either way I doubt that this will be a big issue.
>>>>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>>>>>>>> maybe
>>>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>> bigger issue is how to run arbitrary code
>>>>>>>>>>>>>>>>>>>>>>>>>> efficiently
>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>> securely.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I see only a few solutions
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>       Don't allow arbitrary code, but only a
>>>>>>>>>>>>>>>>>>>>>>>>>> defined
>>>>>>>>>>>>>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>>> tasks.
>>>>>>>>>>>>>>>>>>>>>>>>>>  Or,
>>>>>>>>>>>>>>>>>>>>>>>>>> similarly, allow some "trusted" set of tasks, each
>>>>>>>>>>>>>>>>>>>>>>>>>> separately
>>>>>>>>>>>>>>>>>>>>>>>>>> ported
>>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>> each platform (like boinc).
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>       Use Java.  This lets us easily sandbox it
>>>>>>>>>>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>>>>>>>>>>> cross-platform,
>>>>>>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>>>>>>> sacrifices a bit on efficiency.  Also, Java can be
>>>>>>>>>>>>>>>>>>>>>>>>>> annoying
>>>>>>>>>>>>>>>>>>>>>>>>>> (although
>>>>>>>>>>>>>>>>>>>>>>>>>> other JVM languages would also work in this
>>>>>>>>>>>>>>>>>>>>>>>>>> situation).
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>       There are ways of running cross-platform,
>>>>>>>>>>>>>>>>>>>>>>>>>> C/C++
>>>>>>>>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>> sandbox as
>>>>>>>>>>>>>>>>>>>>>>>>>> well.  One possibility is to use LLVM, although
>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> LLVM
>>>>>>>>>>>>>>>>>>>>>>>>>> developers
>>>>>>>>>>>>>>>>>>>>>>>>>> specifically say that LLVM is NOT designed to be
>>>>>>>>>>>>>>>>>>>>>>>>>> used
>>>>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>>>> way.
>>>>>>>>>>>>>>>>>>>>>>>>>>  Another
>>>>>>>>>>>>>>>>>>>>>>>>>> possibility is to use a sandboxed code system that
>>>>>>>>>>>>>>>>>>>>>>>>>> works
>>>>>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>>>> multiple
>>>>>>>>>>>>>>>>>>>>>>>>>> operating systems but only on x86.  This includes
>>>>>>>>>>>>>>>>>>>>>>>>>> things
>>>>>>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>>>>>>> VX32,
>>>>>>>>>>>>>>>>>>>>>>>>>> which is apparently portable to Windows, but
>>>>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>>>> ported.
>>>>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>> don't know whether or not that sort of thing is
>>>>>>>>>>>>>>>>>>>>>>>>>> within
>>>>>>>>>>>>>>>>>>>>>>>>>> our
>>>>>>>>>>>>>>>>>>>>>>>>>> abilities.
>>>>>>>>>>>>>>>>>>>>>>>>>> Another option might be Google Native Client;
>>>>>>>>>>>>>>>>>>>>>>>>>> that is
>>>>>>>>>>>>>>>>>>>>>>>>>> designed
>>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>> used in a web browser but I don't know how hard it
>>>>>>>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>> "rip
>>>>>>>>>>>>>>>>>>>>>>>>>> out"
>>>>>>>>>>>>>>>>>>>>>>>>>> the sandboxing/cross-OS x86 code stuff.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Michael Cohen
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>> Mailing list: https://launchpad.net/~modred
>>>>>>>>>>>>>>>>>>>>>>>>>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>>>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~modred
>>>>>>>>>>>>>>>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>> Mailing list: https://launchpad.net/~modred
>>>>>>>>>>>>>>>>>>>>>>>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~modred
>>>>>>>>>>>>>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>  _______________________________________________
>>>>>>>>>>>>>>>>>>>>>> Mailing list: https://launchpad.net/~modred
>>>>>>>>>>>>>>>>>>>>>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~modred
>>>>>>>>>>>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  _______________________________________________
>>>>>>>>>>>>>>>>>>>> Mailing list: https://launchpad.net/~modred
>>>>>>>>>>>>>>>>>>>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~modred
>>>>>>>>>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  _______________________________________________
>>>>>>>>>>>>>>>>>> Mailing list: https://launchpad.net/~modred
>>>>>>>>>>>>>>>>>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~modred
>>>>>>>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  _______________________________________________
>>>>>>>>>>>>>>>> Mailing list: https://launchpad.net/~modred
>>>>>>>>>>>>>>>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~modred
>>>>>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Mailing list: https://launchpad.net/~modred
>>>>>>>>>>>>>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~modred
>>>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Scott Lawrence
>>>>>>>>>>>>>
>>>>>>>>>>>>> Webmaster
>>>>>>>>>>>>> The Blair Robot Project
>>>>>>>>>>>>> Montgomery Blair High School
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Mailing list: https://launchpad.net/~modred
>>>>>>>>>>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>> Unsubscribe : https://launchpad.net/~modred
>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Mailing list: https://launchpad.net/~modred
>>>>>>>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>>>>>>> Unsubscribe : https://launchpad.net/~modred
>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~modred
>>>>>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~modred
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~modred
>>>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~modred
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~modred
>>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~modred
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>
>


-- 
Scott Lawrence

Webmaster
The Blair Robot Project
Montgomery Blair High School