[erlang-patches] spawn to rpc, filter, etc.

[Musumeci, Antonio S]

Working within the existing modules only allows us so much flexibility. The RPC protocol doesn't provide any way to provide a security context AFAICT. This patch I've proposed *at least* provides the ability to filter on MFA/From. The only thing you can do currently is to tell kernel_sup to shutdown rex but leaves open spawn and spawn is held inside net_kernel which would cause major breakage if shut down. Leaving rpc/spawn wide open without reasonable ability to tighten up security seems rather strict and unnecessary. It's not unlike the connected port exclusivity patch I'm working on. A few dozen lines of code can restrict communication with ports to only its connected process. Obviously unsecure just doesn't fly in many places and these little changes can go a long way I think in helping Erlang get adopted. RPC 2.0 can always be designed without existing constraints but providing some amount of security within the existing framework is a necessary step to that.

I'll look into making it fully backward compatible. As before suggestions are welcome.

-----Original Message-----
From: erlang-patches@REDACTED [mailto:erlang-patches@REDACTED] On Behalf Of Ulf Wiger
Sent: Monday, March 01, 2010 12:44 PM
To: bile@REDACTED
Cc: erlang-patches@REDACTED; erlang-questions@REDACTED
Subject: Re: [erlang-patches] spawn to rpc, filter, etc.

bile@REDACTED wrote:
> Björn Gustavsson wrote:
>> ...
> 
> I see several easy and minor
> changes to the Erlang system that would go a long way to providing a 
> more secure environment and I'm trying to get them out there so others 
> can take advantage of them.

I'd say that the inability to filter incoming rpc calls is one of the things that push people towards implementing their own communication channels and "user-level rpc".
Improving security would definitely be welcome...

One problem is of course that if you're connected to a node, you can send any message on any process on that node, which is a whopping big security hole.

As an example, the application controller is always pid <0.6.0> (used to be <0.5.0> for many years. If you can only figure out the node index of a remote node, you can do evil stuff like:

NIndex = 6341,  % (or whatever)
P = c:pid(NIndex,6,0),
P ! {'$gen_call', {P,ref}, {stop_application,kernel}}

and render it pretty much useless.

I'm all for incrementally improving the situation, but am hesitant if we don't believe that good-enough security is within reach. Moving from "obviously unsecure" to "not obviously unsecure" is not necessarily an improvement.

>> Therefore, being only a "nice to have" feature that changes sensitive 
>> code paths, the following are the minimum requirements:
>>
>> * It should be 100% backwards compatible.
> 
> I was under the understanding that different releases shouldn't 
> necessarily be used together. It's a rather large jump in security 
> between nodes relative to what exists and I'd think it's a reasonable 
> tradeoff. As I mentioned in the previous email it could be made fully 
> compatible but I don't find it a very appealing solution.

I think it should be 100% bw compatible with old nodes, but old nodes should not need to offer any better security than before. The problem is that there doesn't seem to be a way to tell whether a connected node is old or new.

Users who don't need the added security must still be able to rely on core functionality to be b/w compatible.


> I wouldn't consider it unreasonable if R14 remote spawns didn't work 
> on R13 and prior. Just as I consider it reasonable that by catching 
> throws now in rpc there is a possibility of breakage.

I think there is a difference between these two, and do think that remote spawns cannot be seen to suddenly break.


--
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com

---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com


________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@REDACTED


--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.