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
