Hi Jim
Well I think about Terminal Server and Citrix environments where Java is
used as an infrastructure for Fat Clients. I do not talk about running a web
application server like JBOSS. In case of Fat Clients under Terminal
Server/Citrix these VMs run as independent VMs under the user account of the
user logged into the terminal server session. So there is no shared VM among
users. See the following slides for details on Terminal Server Session
Break-Outs: http://www.iplosion.com/archives/42
You should note that in a Citrix-Environment java.exe is installed by
default since the Citrix administrative console is a Java application.
For me the problem arises when the terminal server session should be locked
down. There are mechanisms which allow interactive users to be restricted to
a set of business applications. What I say is that when java.exe is enabled
then potentially any application can be executed. To avoid this situation a
Java policy would be required. But there is no secure way to enforce them in
the terminal server scenario.
Can you see my point?
Regards Jan
-----Original Message-----
From: jim@manico.net [mailto:jim@manico.net]
Sent: Donnerstag, 21. Dezember 2006 20:36
To: bugtraq@securityfocus.com
Subject: Re: Enforcing Java Security Manager in Restricted Windows
Environments?
You should not deploy java.exe in a shared environments where multiple
trusted users use the same JVM. There are simply to many JVM level
vulnerabilities where one user will be able to use the very recent series of
JVM level bugs that can inspect the running code of another user, not to
mention the problems you mentioned where a user can run Java shells, network
sniffers, and other nasties.
You only want to do this in the J2EE world where you are protected behind
many layers of protections between the user and the JVM.
But what you are suggesting is an environment where many users can directly
share the same JVM, and even with your security policy restrictions, like
you said, I can do some simple OS parameter tampering to get around that.
Answer: do not do it. Shared JVM's only belong in the Servlet/J2EE work -
and even then, JVM level exploits still get exposed from container
endpoints, like we see in JBOSS often.
