modred team mailing list archive

[Scott Lawrence <bytbox@xxxxxxxxx>]

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
>


-- 
Scott Lawrence

Webmaster
The Blair Robot Project
Montgomery Blair High School