esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pollak <>
Subject Re: Scala interpreter action
Date Mon, 06 Jul 2009 14:07:41 GMT
On Mon, Jul 6, 2009 at 1:24 AM, Vassil Dichev <> wrote:

> > Should we remove it completely from the source or should we just
> > deactivate it by default?
> >
> > I agree that I wouldn't activate it in a producticve setting but it
> > might be useful while developing.
> Granted, this might not be the best way to monitor/debug ESME (e.g. if
> memory is so tight the JVM won't be able to create a new interpreter
> instance or send a new message). When I implemented the feature I was
> actually thinking of Dick's request for making it easier for ESME
> newcomers to learn Scala. I've also spent some time thinking about
> using ESME in a university and this feature makes a lot of sense in a
> classroom.
> My point is, I still think it could be made secure with a careful
> java.policy file (which a conscientious administrator should use
> anyway). David, do you think the Scala interpreter is impossible to
> secure or just not worth the effort? Also, what difference would it
> make to use Rhino, but not Scala in terms of a secure interpreter? The
> Scala interpreter implementation does use a new classloader and even
> allows you to override it and implement your own one. Try e.g. "import
> org.apache.esme.model.Message" or "import net.liftweb.util.Box".

Upon more reflection, I think any form of code that can read/write files on
the local filesystem and/or open TCP connections to localhost or anywhere
else presents a danger.  Think about how long it took to secure
browser-based Java implementations.  I just see a high resource consumption
cycle of finding hole/fixing hole... all for a feature that's not part of
the main purpose of the project.

The above comments apply to Scala as well as JavaScript via Rhino... I just
don't think it can be done securely.

With that being said, what I propose is keeping the code in, having it
disabled by default, making sure there's a huge warning associated with the
option that it gives users a lot of power on the machine and it should only
be enabled if you're running behind a firewall and with only known and
trusted users.  Finally, when I get the federation stuff in, I'll disable
federation with any instance that has this feature turned on.  That'll calm
my concerns about network attacks.



PS -- I really do like this feature in the abstract.  I think it's cool.
It's the former CTO of a security company part of me that rears its ugly
head when I see stuff that allows for semi-controlled code to be executed
from unknown parties.

> If the primary concern is trust in a federation, we could make it so a
> server is not allowed to participate in a federation if the Scala
> interpreter action is enabled.
> Cheers,
> Vassil

Lift, the simply functional web framework
Beginning Scala
Follow me:
Git some:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message