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

[Hynek Vychodil]

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