Hi Scott,
Yes, we plan to run each user with separate JVM's. That seems to be half of the battle for us. The other issue that we are facing is users reading/manipulating files at will on the server. Because we are using it in and ISP environment we have a lot of potential for malicious code. I am not 100% sure that separating the JVM will handle all possibilities for security issues? Do you think that this would be enough? I need to do more research about ALL of the security loopholes with Java that I need to be concerned with. I think that it will be best to CHROOT resin. I don't know about this as I have not attempted it. I am very concerned that a user can read the groups file, passwd file, hosts file etc with Java IO. I appreciate your help as I'm struggling to find the right answer. Thanks, Joey _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: Monday, February 11, 2008 7:15 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 2008-02-11 snapshot On Feb 11, 2008, at 5:12 PM, Mktg. Incorporate Fast wrote: Hi Knut, We are trying to get it right from a security perspective. The JRE by default in a web service environment provides a great amount of security loop holes that make virtual hosting with Java very dangerous. I am still hopeful that I can find a good solution to this problem. I am a little baffled that the design of the JRE/web server has not made it simpler to segregate hosts from each other and the root server. I think that this should be the default. Is it possible for each user to have their own JVM? In that case, the user-name would protect with normal unix permissions. -- Scott I would argue that the individual by default should not be allowed to interface with anything not inside of its host folder. If the application needs to have access to the server wide resources, then extra work should be required. In my opinion, this would make Java more secure. I think that I need to experiment with CHROOT of the resin environment. I have not done this before, so I assume it will be both quick and fun. Appreciate your response very much. Thank you, Joey _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Knut Forkalsrud Sent: Monday, February 11, 2008 4:48 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 2008-02-11 snapshot I wouldn't classify my setup as ISP environment. We have a handful of web applications that have a more or less independent lifecycle in terms of upgrades, availability requirements and so on. Also I have always favored running each application compartmentalized as much as reasonably possible. For me that means separate JVM, running as a separate user on the server. A chroot jail could be useful as well, but I haven't pursued that yet. The code in question is all our own, so we trust all the apps to be well behaved. Still we want to keep them separate, so for example an out of memory condition will only affect one app. I haven't done any work involving the security manager, other than a dirty hack to allow one brain dead library to work. We're on Linux servers. -Knut Mktg. Incorporate Fast wrote: Hello Knut, Are you hosting in an ISP environment? If, so I am trying to enable resin to do the same. Can you please help me by describing the OS and method that you are using resin in an ISP environment to allow multiple hosts on 1 server? I am having difficulty with enabling resin in an ISP environment because of the security issues with JAVA. I am enabling JRE w/ the security manager during testing but that appears to be quite slow. With your environment are you able to provide a fully secure virtual host environment? If so I'd love to hear any suggestions that you may have to help me setup this. Thanks, Joey -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Knut Forkalsrud Sent: Monday, February 11, 2008 4:01 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 2008-02-11 snapshot Scott Ferguson wrote: I thought #2410 was different. If the watchdog-port is the same for several instances (or unset) it was possible for a server to get stuck, so you couldn't start or stop it. Since that would be an annoying situation, I'd like to track that down an fix it. Ok, here is a scenario: User A and user B have their files hidden from each other (as in chmod go-r). User A starts Resin, thereby starting the watchdog. User B tries to start its own Resin instance, which fails, because the (already running) watchdog cannot see the files owned by B. Instead B gets an error message saying something like "No such file or directory: /home/B/web/conf/resin.conf" -Knut _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
_______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
