Re: Securing remote spawning
Locked
Re: Securing remote spawning
 
|
Hi,
Thanks, but basically that means that I have to trust the firewall. If somebody gets past the first "layer of defense", they can do more damage. With great power..... --Maarten ---------------------------------- From: "Gleb Peregud" <[hidden email]> Date: 4/23/08 17:53Subject: Re: [erlang-questions] Securing remote spawning Hi, No. At this moment there is no such mechanism (at least none i heard of). Erlang security is based on simple concept of "secret cookie". If one knows cookie of running node then he gets absolute power over this node. Same goes to inter-node communication - if two nodes share the same cookie they trust each other fully. If it differs - they do not communicate at all. For details see http://www.erlang.org/doc/reference_manual/distributed.html#11.7 Of course you can roll out your own mechanism. For specific task with term_to_binary/1 and binary_to_term/1 is should not be too hard. Also you may want to read this: http://www.trapexit.org/Distributed_erlang_using_ssl_through_firewalls Best regards. On 4/23/08, Maarten Koopmans <[hidden email]> wrote: > Hi, > > New to this list and Erlang, and I have a simple question that I > couldn't find an answer to in any of the docs: is it possible to > restrict the possibility of remote spawning or rpc on a given set of > nodes to only a subset of the functions? > > Because if I think "trust no one" then only cookies for SaaS > applications imply that I loose a layer of defense (and have only the > firewall left). Especially because the Big Plus with Erlang woudl be > using Mnesia as well - but this implies moving all code busines + Db) in > the same zone. > > The only option I can think of is doing all communication socket based > with custom protocols/DSLs that limit what you can do. > > Any help/insights greatly appreciated! > > --Maarten > _______________________________________________ > erlang-questions mailing list > [hidden email] > http://www.erlang.org/mailman/listinfo/erlang-questions > -- Gleb Peregud http://gleber.pl/ Every minute is to be grasped. Time waits for nobody. -- Inscription on a Zen Gong _______________________________________________ erlang-questions mailing list [hidden email] http://www.erlang.org/mailman/listinfo/erlang-questions |
Re: Securing remote spawning
|
Hi,
No it doesn't mean you have to trust the firewall, all it means is that you cannot use the built in erlang distribution for communication with untrusted clients. It is very easy to roll your own RPC: call(Sock, M,F,A) -> gen_tcp:send(Sock, erlang:term_to_binary(M,F,A)). Then at the other end: receive {tcp, Sock, Data} -> case erlang:term_to_binary(Data) of {M, F, A} when is_list(A) -> case lists:member({M,F,length(A)}, Allowed_funcs) of true -> apply(M,F,A); false -> ignore end; _ -> ignore end etc Sean On 23 Apr 2008, at 19:39, <[hidden email]> <[hidden email]> wrote: > Hi, > > Thanks, but basically that means that I have to trust the firewall. > If somebody gets past the first "layer of defense", they can do more > damage. With great power..... > > --Maarten > > > > ---------------------------------- > From: "Gleb Peregud" <[hidden email]> > Date: 4/23/08 17:53Subject: Re: [erlang-questions] Securing > remote spawning > > Hi, > > No. At this moment there is no such mechanism (at least none i heard > of). Erlang security is based on simple concept of "secret cookie". If > one knows cookie of running node then he gets absolute power over this > node. Same goes to inter-node communication - if two nodes share the > same cookie they trust each other fully. If it differs - they do not > communicate at all. > > For details see http://www.erlang.org/doc/reference_manual/distributed.html#11.7 > > Of course you can roll out your own mechanism. For specific task with > term_to_binary/1 and binary_to_term/1 is should not be too hard. > > Also you may want to read this: > http://www.trapexit.org/Distributed_erlang_using_ssl_through_firewalls > > Best regards. > > On 4/23/08, Maarten Koopmans <[hidden email]> wrote: >> Hi, >> >> New to this list and Erlang, and I have a simple question that I >> couldn't find an answer to in any of the docs: is it possible to >> restrict the possibility of remote spawning or rpc on a given set of >> nodes to only a subset of the functions? >> >> Because if I think "trust no one" then only cookies for SaaS >> applications imply that I loose a layer of defense (and have only the >> firewall left). Especially because the Big Plus with Erlang woudl be >> using Mnesia as well - but this implies moving all code busines + >> Db) in >> the same zone. >> >> The only option I can think of is doing all communication socket >> based >> with custom protocols/DSLs that limit what you can do. >> >> Any help/insights greatly appreciated! >> >> --Maarten >> _______________________________________________ >> erlang-questions mailing list >> [hidden email] >> http://www.erlang.org/mailman/listinfo/erlang-questions >> > > > -- > Gleb Peregud > http://gleber.pl/ > > Every minute is to be grasped. > Time waits for nobody. > -- Inscription on a Zen Gong > _______________________________________________ > erlang-questions mailing list > [hidden email] > http://www.erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list [hidden email] http://www.erlang.org/mailman/listinfo/erlang-questions |
Re: Securing remote spawning
|
Sean Hinde writes:
> It is very easy to roll your own RPC: > > call(Sock, M,F,A) -> > gen_tcp:send(Sock, erlang:term_to_binary(M,F,A)). > > Then at the other end: > > receive > {tcp, Sock, Data} -> > case erlang:term_to_binary(Data) of > {M, F, A} when is_list(A) -> > case lists:member({M,F,length(A)}, Allowed_funcs) of > true -> > apply(M,F,A); > false -> > ignore > end; > _ -> ignore > end > > etc This example illustrates the general idea, and you can (and should!) robustify it in practice if you want to deal with potentially malicious clients. A starting point would be to eliminate binary_to_term/1 (which is what Sean meant to write in the 'receive' above, where he wrote 'term_to_binary'). binary_to_term/1 is too general and too powerful. Not only can a client launch a DOS attack using it (by overflowing the atom table), but there have been quite a few examples of how to crash the emulator with it: http://www.erlang.org/pipermail/erlang-questions/2001-June/003332.html http://www.erlang.org/pipermail/erlang-questions/2006-February/018901.html http://www.erlang.org/pipermail/erlang-bugs/2008-February/000634.html Matt _______________________________________________ erlang-questions mailing list [hidden email] http://www.erlang.org/mailman/listinfo/erlang-questions |
Re: Securing remote spawning
|
Couldn't the ssh lib be used in order to do authenticated rpc calls ? --Tobbe Matthias Lang wrote: > Sean Hinde writes: > > > It is very easy to roll your own RPC: > > > > call(Sock, M,F,A) -> > > gen_tcp:send(Sock, erlang:term_to_binary(M,F,A)). > > > > Then at the other end: > > > > receive > > {tcp, Sock, Data} -> > > case erlang:term_to_binary(Data) of > > {M, F, A} when is_list(A) -> > > case lists:member({M,F,length(A)}, Allowed_funcs) of > > true -> > > apply(M,F,A); > > false -> > > ignore > > end; > > _ -> ignore > > end > > > > etc > > This example illustrates the general idea, and you can (and should!) > robustify it in practice if you want to deal with potentially > malicious clients. > > A starting point would be to eliminate binary_to_term/1 (which is what > Sean meant to write in the 'receive' above, where he wrote > 'term_to_binary'). binary_to_term/1 is too general and too > powerful. Not only can a client launch a DOS attack using it (by > overflowing the atom table), but there have been quite a few examples > of how to crash the emulator with it: > > http://www.erlang.org/pipermail/erlang-questions/2001-June/003332.html > http://www.erlang.org/pipermail/erlang-questions/2006-February/018901.html > http://www.erlang.org/pipermail/erlang-bugs/2008-February/000634.html > > Matt _______________________________________________ erlang-questions mailing list [hidden email] http://www.erlang.org/mailman/listinfo/erlang-questions |
Re: Securing remote spawning
|
|
In reply to this post by Maarten Koopmans
That was what I was expecting (as a mechanism). This looks like Erlang is vey powerful but the power cannot be contained easily in non-closed (or non-trusted) environments.
Because if I understand correctly, I'd also have to shut down the "default" remote spawning mechanism on the receiving side. --Maarten --------------------------------------------------------- From: Torbjorn Tornkvist <[hidden email]> Date: 4/23/08 20:49Subject: Re: [erlang-questions] Securing remote spawning Couldn't the ssh lib be used in order to do authenticated rpc calls ? --Tobbe Matthias Lang wrote: > Sean Hinde writes: > > > It is very easy to roll your own RPC: > > > > call(Sock, M,F,A) -> > > gen_tcp:send(Sock, erlang:term_to_binary(M,F,A)). > > > > Then at the other end: > > > > receive > > {tcp, Sock, Data} -> > > case erlang:term_to_binary(Data) of > > {M, F, A} when is_list(A) -> > > case lists:member({M,F,length(A)}, Allowed_funcs) of > > true -> > > apply(M,F,A); > > false -> > > ignore > > end; > > _ -> ignore > > end > > > > etc > > This example illustrates the general idea, and you can (and should!) > robustify it in practice if you want to deal with potentially > malicious clients. > > A starting point would be to eliminate binary_to_term/1 (which is what > Sean meant to write in the 'receive' above, where he wrote > 'term_to_binary'). binary_to_term/1 is too general and too > powerful. Not only can a client launch a DOS attack using it (by > overflowing the atom table), but there have been quite a few examples > of how to crash the emulator with it: > > http://www.erlang.org/pipermail/erlang-questions/2001-June/003332.html > http://www.erlang.org/pipermail/erlang-questions/2006-February/018901.html > http://www.erlang.org/pipermail/erlang-bugs/2008-February/000634.html > > Matt erlang-questions mailing list [hidden email] http://www.erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list [hidden email] http://www.erlang.org/mailman/listinfo/erlang-questions |
Re: Securing remote spawning
|
|
If you allow authentication and connection via the normal erlang
distribution then everything is wide open. If you do not allow this connection (e.g. by forewall, and having a secret cookie), and hence only allow a custom protocol then you can control it completely. There is no "default" remote spawning over my proposed protocol, or HTTP or... Sean On 23 Apr 2008, at 21:59, <[hidden email]> wrote: > That was what I was expecting (as a mechanism). This looks like > Erlang is vey powerful but the power cannot be contained easily in > non-closed (or non-trusted) environments. > > Because if I understand correctly, I'd also have to shut down the > "default" remote spawning mechanism on the receiving side. > > --Maarten > > --------------------------------------------------------- > > > From: Torbjorn Tornkvist <[hidden email]> > Date: 4/23/08 20:49Subject: Re: [erlang-questions] Securing > remote spawning > > > Couldn't the ssh lib be used in order to do authenticated rpc calls ? > > --Tobbe > > > Matthias Lang wrote: >> Sean Hinde writes: >> >>> It is very easy to roll your own RPC: >>> >>> call(Sock, M,F,A) -> >>> gen_tcp:send(Sock, erlang:term_to_binary(M,F,A)). >>> >>> Then at the other end: >>> >>> receive >>> {tcp, Sock, Data} -> >>> case erlang:term_to_binary(Data) of >>> {M, F, A} when is_list(A) -> >>> case lists:member({M,F,length(A)}, Allowed_funcs) of >>> true -> >>> apply(M,F,A); >>> false -> >>> ignore >>> end; >>> _ -> ignore >>> end >>> >>> etc >> >> This example illustrates the general idea, and you can (and should!) >> robustify it in practice if you want to deal with potentially >> malicious clients. >> >> A starting point would be to eliminate binary_to_term/1 (which is >> what >> Sean meant to write in the 'receive' above, where he wrote >> 'term_to_binary'). binary_to_term/1 is too general and too >> powerful. Not only can a client launch a DOS attack using it (by >> overflowing the atom table), but there have been quite a few examples >> of how to crash the emulator with it: >> >> http://www.erlang.org/pipermail/erlang-questions/2001-June/003332.html >> http://www.erlang.org/pipermail/erlang-questions/2006-February/018901.html >> http://www.erlang.org/pipermail/erlang-bugs/2008-February/ >> 000634.html >> >> Matt > > _______________________________________________ > erlang-questions mailing list > [hidden email] > http://www.erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > [hidden email] > http://www.erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list [hidden email] http://www.erlang.org/mailman/listinfo/erlang-questions |
Re: Securing remote spawning
|
In reply to this post by Sean Hinde
On Wed, Apr 23, 2008 at 08:29:11PM +0100, Sean Hinde wrote: > Hi, > > No it doesn't mean you have to trust the firewall, all it means is > that you cannot use the built in erlang distribution for communication > with untrusted clients. It is very easy to roll your own RPC: > > call(Sock, M,F,A) -> > gen_tcp:send(Sock, erlang:term_to_binary(M,F,A)). > > Then at the other end: > > receive > {tcp, Sock, Data} -> > case erlang:term_to_binary(Data) of > {M, F, A} when is_list(A) -> > case lists:member({M,F,length(A)}, Allowed_funcs) of > true -> > apply(M,F,A); > false -> > ignore > end; > _ -> ignore > end > > etc > > Sean ... which is then communicated via a secure SSL channel to reduce the possibility of third party eavesdropping ~Michael > > > On 23 Apr 2008, at 19:39, <[hidden email]> > <[hidden email]> wrote: > > Hi, > > > > Thanks, but basically that means that I have to trust the firewall. > > If somebody gets past the first "layer of defense", they can do more > > damage. With great power..... > > > > --Maarten > > > > > > > > ---------------------------------- > > From: "Gleb Peregud" <[hidden email]> > > Date: 4/23/08 17:53Subject: Re: [erlang-questions] Securing > > remote spawning > > > > Hi, > > > > No. At this moment there is no such mechanism (at least none i heard > > of). Erlang security is based on simple concept of "secret cookie". If > > one knows cookie of running node then he gets absolute power over this > > node. Same goes to inter-node communication - if two nodes share the > > same cookie they trust each other fully. If it differs - they do not > > communicate at all. > > > > For details see http://www.erlang.org/doc/reference_manual/distributed.html#11.7 > > > > Of course you can roll out your own mechanism. For specific task with > > term_to_binary/1 and binary_to_term/1 is should not be too hard. > > > > Also you may want to read this: > > http://www.trapexit.org/Distributed_erlang_using_ssl_through_firewalls > > > > Best regards. > > > > On 4/23/08, Maarten Koopmans <[hidden email]> wrote: > >> Hi, > >> > >> New to this list and Erlang, and I have a simple question that I > >> couldn't find an answer to in any of the docs: is it possible to > >> restrict the possibility of remote spawning or rpc on a given set of > >> nodes to only a subset of the functions? > >> > >> Because if I think "trust no one" then only cookies for SaaS > >> applications imply that I loose a layer of defense (and have only the > >> firewall left). Especially because the Big Plus with Erlang woudl be > >> using Mnesia as well - but this implies moving all code busines + > >> Db) in > >> the same zone. > >> > >> The only option I can think of is doing all communication socket > >> based > >> with custom protocols/DSLs that limit what you can do. > >> > >> Any help/insights greatly appreciated! > >> > >> --Maarten > >> _______________________________________________ > >> erlang-questions mailing list > >> [hidden email] > >> http://www.erlang.org/mailman/listinfo/erlang-questions > >> > > > > > > -- > > Gleb Peregud > > http://gleber.pl/ > > > > Every minute is to be grasped. > > Time waits for nobody. > > -- Inscription on a Zen Gong > > _______________________________________________ > > erlang-questions mailing list > > [hidden email] > > http://www.erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > [hidden email] > http://www.erlang.org/mailman/listinfo/erlang-questions -- Michael McDaniel Portland, Oregon, USA http://autosys.us +1 503 283 5284 _______________________________________________ erlang-questions mailing list [hidden email] http://www.erlang.org/mailman/listinfo/erlang-questions |
Re: Securing remote spawning
|
In reply to this post by Maarten Koopmans
I've also been thinking about these issues: how to make use of Erlang distributed features but more adaptable than the all-or-nothing cookie. The lib_chan modules in Joe's book describe one way of implementing password protected access to server processes that are listening on specified ports. It would of course be nice to have similar functionality but in the Erlang machinery.
I'm thinking of a Erlang node that is open for remote messages but only from nodes that have been authenticated and authorized. Starting to think in these terms is of course opening a big box of questions: is authorization tied to a node or a process, can a process delegate rights, can a registered process send any pid in a reply message and can this pid be used even if that process has not been registered, what happens if we send functions in messages, will these functions have access to any module on the receiving side, can we provide a sand-box with limited computational resources, ... not to mention the different authorization schemes that one could use. I'll hope to have more time to look at this so if anyone have ideas on what functionality is desired I'm interested. Johan -- KTH ICT Johan Montelius _______________________________________________ erlang-questions mailing list [hidden email] http://www.erlang.org/mailman/listinfo/erlang-questions |
«
Return to Erlang Questions
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |