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

[Ulf Wiger]

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