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

[Garrett Smith]

On Mon, Mar 1, 2010 at 9:54 AM,  <bile@REDACTED> wrote:
> Björn Gustavsson wrote:
>> I consider this feature "nice to have". It does not provide enough
>> additional security so that you would dare to connect to untrusted
>> nodes, so the ability to filter messages can only be a convenience
>> feature, not a game changing feature. (As far as I can understand.
>> You have not mentioned any specific applications that would have
>> a need for the feature.)
>
> Currently there is nearly zero security outside of the cookie. There are
> cases where native connected nodes are desired without opening up the
> entire system. Trust is not binary. Just because I can ssh to a box
> doesn't mean I can execute anything on the machine. My team is currently
> rewriting an application in Erlang and we must have certain levels of lock
> down. There are always tradeoffs for security but Erlang in its current
> form forces tradeoffs that aren't necessary. 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.
>
>>
>> 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.
>
>> * It should not reduce the performance for applications
>> that don't use (and have no use for) the new feature.
>
> Within reason, agreed. In this case if the filter isn't set 'apply' is
> called directly. There is only wrapper function with a guard as overhead.
>
>> * It should be obviously correct and harmless. (It is
>> embarrassing for the Erlang/OTP team if a new killer feature
>> breaks something that has always worked. It is *very*
>> embarrassing if a not specially important features breaks
>> something.)
>
> Obviously. That's why pu and unit exists is it not? I'll be happy to write
> some additional unit tests I've just not had the time. However, there is a
> difference between purposeful breakage in the name of advancement and
> breakage due to bad code. Security in Erlang has been talked about a lot
> but little is done. This patch provides a certain amount of security
> without any major impact. 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.
>
>>
>> Unless you can convince us that the feature is more
>> important than just "nice to have", it is unlikely that we
>> will approve it.
>
> I'm hoping more people comment on the feature. In my short time in the
> Erlang community I've seen a few individuals ask about sandboxing beam
> and/or networked nodes. The former would require a lot of work but the
> latter is straight forward if an ability to plugin to remote 'apply'ing is
> provided. I've CCed erlang-questions to bring a larger audience.

I can only speak of my experiences and inclination, but baking
security into a language environment is not really a bolt-on feature.
A 99% "security measure" is a total disaster -- much worse than no
security. I'm not weighing in on "how good" the patch/proposal is,
only that this type of change should be taken very seriously. I think
it's fair that Björn wants to understand more about why this is more
than "nice to have".

Again, strictly my opinion, but having worked quite a bit with Java's
security model, I believe it's a total PITA -- both to use and work
around. There are undoubtedly lots of people who love it and use it
effectively, but I strictly avoid it.

I'm more comfortable working within the security model of the OS. E.g.
running as non-privileged, file permissions, iptables, etc. There's a
lot you can do to lock down a program or network -- and that with very
mature, proven technology.

As far as node-to-node connectivity, I'm leaning away from Erlang's
native "mesh" features and more toward messaging using brokers (e.g.
rabbitmq, qpid, etc.) I know Erlang's "distributed story" is
predicated on these features, but there some good reasons to turn
those off and use brokers, security/access control being one of them.
I realize, however, this is a non starter for typical distributed
Erlang apps -- just too much work.

Garrett