On Mon, Jul 6, 2009 at 1:24 AM, Vassil Dichev <[email protected]> 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. Thanks, David 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 http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp
