Securing Erlang internals

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Securing Erlang internals

Mikl Kurkov
In my current project I have a client part that will be deployed to untrusted computers,
and I'm thinking about the ways of closing Erlang node internals from inspection.
Now it's too easy to load some beams to erlang, run module_info and try to run some interesting funs.
I understand that it's not possible to make it totaly secured as we have got access to machine internals,
but I would like to make it not so easy as it is.
Ideally it should look like ordinal compiled program and to understand it internals you will have
to disasm it.

For now I see several approaches:
1. SAE - not seems to work with R12B
2. Making some bundle of Erlang runtime, libs and app beams.  
As example - Silly SAE (http://git.erlang.geek.nz/?p=ssae.git;a=summary) approach - loading beams from archive.
3. Making some source code obfuscation (renaming modules and exported function to meaningless names).
As I'm not manipulate this names in app it seems to be possible to do.

So what would you suggest? May be someone already faced with such a task.
May be there are some tools for bundling several files into one binary.

Thanks in advance,
Mikl
Reply | Threaded
Open this post in threaded view
|

Re: Securing Erlang internals

Richard Andrews-4
I've been asked to do such things with python which has similar problems and
IMO there is no security to be gained from doing such a thing. You will make
life uncessarily difficult for yourself (troubleshooting) and the customer.

If the knowledge of internals of the client is sufficient to allow an attack on
the server then there is no security in the application.

It sounds to me like this is about intellectual property concerns rather than
security.

--- Mikl Kurkov <[hidden email]> wrote:

>
> In my current project I have a client part that will be deployed to untrusted
> computers,
> and I'm thinking about the ways of closing Erlang node internals from
> inspection.
> Now it's too easy to load some beams to erlang, run module_info and try to
> run some interesting funs.
> I understand that it's not possible to make it totaly secured as we have got
> access to machine internals,
> but I would like to make it not so easy as it is.
> Ideally it should look like ordinal compiled program and to understand it
> internals you will have
> to disasm it.



      Get the name you always wanted with the new y7mail email address.
www.yahoo7.com.au/y7mail


_______________________________________________
erlang-questions mailing list
[hidden email]
http://www.erlang.org/mailman/listinfo/erlang-questions