[erlang-questions] Securely running code on an untrusted client

Tue Jan 8 17:56:36 CET 2008

I'll have to ponder on the SETI/Boinc option.

Like I said originally, I didn't think it was possible, but there are a lot
of people in this community smarter than me, so I figured it wouldn't hurt
to ask. :)

tj

On Jan 8, 2008 1:31 AM, Hynek Vychodil <vychodil.hynek@REDACTED> wrote:

> This is insecure by principle like DRM. It can't work any way really
> secure. All methods what you can use will be only security by
> obscurity ant it isn't real security.
>
> What if I use tweaked VM?
> What if I use tweaked network layer.
> What if I use tweaked kernel.
> What if I use virtual machine for run hosting OS?
>
> You can't solve it! You must trust at least some client even use
> SETI/Boinc redundant approach.
>
> On 1/7/08, Ulf Wiger (TN/EAB) <ulf.wiger@REDACTED> wrote:
> > Travis Jensen skrev:
> > > Thanks for the reply, Ulf.  This seems like the inverse of what I
> want,
> > > if I'm understanding it correctly.  This allows the client to run
> > > untrusted code on the server, right?  What I want is to have the
> server
> > > run trusted code on the client and be able to trust the result.
> >
> > Ok, sorry for the sloppy interpretation.
> >
> > It seems as if you have to decide upon which level of trust
> > to extend to the client, and then live with that. Unless
> > you know exactly what the result of the computation will
> > be, I think it ought to be extremely difficult to get any
> > guarantees...
> >
> > But if you can run an Erlang VM on the client, you can take
> > some precautions to make sure that the client doesn't
> > easily tamper with it:
> >
> > - maintain a secure connection with the VM, to make sure
> >    that it's not shut down and replaced with something
> >    else
> > - don't provide a shell (e.g. via to_erl) on the client
> > - don't run distributed Erlang on it, or if you do,
> >    try to use a really obscure cookie that you set after
> >    erlang is started (this means you must bring up the
> >    net kernel manually)
> > - This way, there is no way to start a shell session
> >    on the VM, or access the RPC server in order to
> >    e.g. load suspicious code.
> >
> > If you then send code and requests along the secure
> > channel, you should be pretty safe.
> >
> > (I'm sure there are variations on the above theme.)
> >
> > BR,
> > Ulf W
> >
> > >
> > > So, let me break it down a little more...
> > >
> > > - Client connects to server.
> > > - Server sends code to client
> > > - Client runs process
> > > - Clients sends result to server
> > > - Server trusts client result
> > >
> > > In the middle of this is the fact that I don't really trust the
> client,
> > > so I would have to know that the result I get from the client is
> > > actually the result of running the process I sent to the client and
> not
> > > the result of some hack.  In general, there are two hack concerns:
> > > hacking the running process to process differently and hacking the
> > > resulting data stream to give a fake result.
> > >
> > > I realize that this may be wishful thinking, but a month ago, having a
> > > system that would scale significantly without introducing unbelievable
> > > complexity into my code was also wishful thinking; then I found
> Erlang. :)
> > >
> > > tj
> > >
> > > On Jan 7, 2008 12:01 AM, Ulf Wiger (TN/EAB) <ulf.wiger@REDACTED
> > > <mailto:ulf.wiger@REDACTED>> wrote:
> > >
> > >     Travis Jensen skrev:
> > >      > I've been looking around online and haven't seen anything to
> > >     contradict
> > >      > what I assume to be the case, but I'm unfamiliar enough with
> > >     Erlang that
> > >      > I figure I should ask.
> > >      >
> > >      > Assuming I have a server on one system and a client on another
> system
> > >      > that exists out somewhere else in the broad, scary internet.
>  The
> > >     server
> > >      > is trusted, the client is not.  The network connection between
> > >     the two
> > >      > is not trusted.
> > >      >
> > >      > Is there any way to run trusted code on the client?
> > >
> > >     As far as I know, the closest you will get right now with
> > >     Erlang is ErlHive.
> > >
> > >       http://erlhive.sourceforge.net/
> > >
> > >     ErlHive is sort of presented as a web application development
> > >     framework, but is really mainly a multi-user back-end with
> > >     safe code execution. It happens to have a front-end application
> > >     which hooks into Yaws, and enables user authentication via
> > >     HTTP.
> > >
> > >     ErlHive is able to compile modules from source, or interpret
> > >     erlang expressions. It forbids operations that are not known
> > >     to be safe, but also offers safe alternatives to many
> > >     operations that normally wouldn't be: a virtual file system,
> > >     process spawning, send & receive, ets tables, etc. All code
> > >     runs inside mnesia transactions.
> > >
> > >     BR,
> > >     Ulf W
> > >
> > >
> > >
> > >
> > > --
> > > Travis Jensen
> > > travis.jensen@REDACTED <mailto:travis.jensen@REDACTED>
> > > http://cmssphere.blogspot.com/
> > > Software Maven * Philosopher-in-Training * Avenged Nerd
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > erlang-questions mailing list
> > > erlang-questions@REDACTED
> > > http://www.erlang.org/mailman/listinfo/erlang-questions
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
>
>
> --
> --Hynek (Pichi) Vychodil
>

-- 
Travis Jensen
travis.jensen@REDACTED
http://softwaremaven.innerbrain.com/
Software Maven * Philosopher-in-Training * Avenged Nerd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080108/41ab1a42/attachment.htm>