servlets-ssi.renametojar
Hello, I'm currently looking into the security issues pertaining to enabling this by default. I followed the conversation for why it is the way it is, but now that I'm actually in the guts of the thing, I don't think I fully understand. The issue as I remember it is that the SsiExec class in servlets-ssi.jar could be exploited even if SSI support wasn't enabled in the web.xml file. The part I'm fuzzy on is how this can be true. Since servlets-ssi.jar is loaded into the server class loader (server/lib) it seems to me that it would be impossible for a rogue webapp to access any classes in this jar. In any case, my solution should protect from these kinds of attacks also, I'm just not sure they're possible. I'll be submitting a patch shortly that should allow SSI support to be enabled by default but would require a specific configuration change to get the exec directive to work. -Paul Speed P.S.: I'd be curious to know of anyone actually using the exec directive. Looking at the code, I'm not sure I see how it works for non-CGI stuff. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: servlets-ssi.renametojar
Glenn Nielsen wrote: I am pleased to see the interest in security issues. But when developing solutions for security issues we need to remember that Tomcat4 can use the Java SecurityManager. And in almost all cases the security needed can be achieved by using catalina.policy. We should leverarge the Java SecurityManager as much as possible to solve these types of security issues rather than writing and relying on our own code to enforce security. The issue you are addressing Paul can also be addressed by my PROPOSAL a week ago. If Tomcat is running with the Java SecurityManager the SSI servlet can't perform an exec unless it has been granted permission to do so. Yes. I like it. I hadn't thought about creating yet another class area to provide finer grain security for just the catalina servlets. I'll have to search for your original proposal and take a look. More below... -- 1. Create $CATALINA_HOME/servlets/lib and $CATALINA_HOME/servlets/classes. This is where global servlets provided with Tomcat 4 can be installed. 2. Move the following jar files into $CATALINA_HOME/servlets/lib servlets-cgi.renametojar servlets-common.jar servlets-default.jar servlets-invoker.jar servlets-manager.jar servlets-snoop.jar servlets-ssi.jar servlets-webdav.jar 3. Update the class loader creation in Bootstrap.java for the catalina loader to look for jar files and classes in $CATALINA_HOME/servlets in addition to $CATALINA_HOME/server. 4. Update the default catalina.policy so that it provides explicit permissions for each jar file in $CATALINA_HOME/servlets/lib. 5. Update the documentation regarding the above changes. Please vote +1 so I can implement the above changes. -- I'm not a committer but I'm willing to help with this. So that's my +1 for what it's worth. It is time to consider making use of the Java SecurityManager the default startup option for Tomcat, or even require that Tomcat be run with the Java SecurityManager. I agree. I had heard horror stories about getting tomcat to run with the security manager, but I found it very easy. It took me a bit to figure out that the server class loader runs with AllPermission and that's why Runtime.exec() is allowed in these servlets. I think that even with moving the servlets to their own area that the server policy should probably be finer grained. AllPermission is convenient but there are clearly a few things that that even these classes shouldn't be allowed to do. (Runtime.exec for example) Having the server area explicitly spell out its security needs will also make fine-tuning that security easier for the more paranoid sys admins. All that being said, my patches for disabling the exec directive might still be useful. Since it simply removes the directive from consideration it causes it to be treated as an unknown command rather than a security error. Currently, unknown commands can be ignored with the correct option. In an ideal world, all of the directives would be configurable but that seemed like overkill. Anyway, I'm going to try and setup your proposal here locally and see if I find any problems. -Paul Regards, Glenn Paul Speed wrote: Hello, I'm currently looking into the security issues pertaining to enabling this by default. I followed the conversation for why it is the way it is, but now that I'm actually in the guts of the thing, I don't think I fully understand. The issue as I remember it is that the SsiExec class in servlets-ssi.jar could be exploited even if SSI support wasn't enabled in the web.xml file. The part I'm fuzzy on is how this can be true. Since servlets-ssi.jar is loaded into the server class loader (server/lib) it seems to me that it would be impossible for a rogue webapp to access any classes in this jar. In any case, my solution should protect from these kinds of attacks also, I'm just not sure they're possible. I'll be submitting a patch shortly that should allow SSI support to be enabled by default but would require a specific configuration change to get the exec directive to work. -Paul Speed P.S.: I'd be curious to know of anyone actually using the exec directive. Looking at the code, I'm not sure I see how it works for non-CGI stuff. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe,
Re: servlets-ssi.renametojar
Glenn Nielsen wrote: [snip] Glad to hear you had success using Tomcat with the Java SecurityManager. Where I work we have several different installs of Tomcat. All of them use a much more restrictive policy file than the default catalina.policy. At one point the Tomcat 4 Security Manager docs included an example of a more restrictive policy than the default catalina.policy that Tomcat 4 is distributed with. If I have time, I will update those docs for the Tomcat 4.0.2 release. And perhaps add an example catalina.policy to the distribution which is more restrictive. Hmmm, now that the framework is there for the admin web application, perhaps an easier to understand interface could be added to if for configuring the catalina.policy file. I may have to take a look at these examples. Trying to whittle down AllPermission by guess work is a daunting task to say the least. ;) I'll RTFM before I complain too loudly. :) All that being said, my patches for disabling the exec directive might still be useful. Since it simply removes the directive from consideration it causes it to be treated as an unknown command rather than a security error. Currently, unknown commands can be ignored with the correct option. In an ideal world, all of the directives would be configurable but that seemed like overkill. Yes, that might be useful. I just don't want to see Tomcat 4 littered with alot of 'security' code when security can be enforced using the Java SecurityManager and a policy file. I whole-heartedly agree with that. -Paul Anyway, I'm going to try and setup your proposal here locally and see if I find any problems. Let me know how it works out. Thanks, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: servlets-ssi.renametojar
Hello,
In my playing around with security, I've been attempting to break-out
the AllPermission for the $(catalina.home}/server classes into
something more granular to allow more refined tweaking. Here's what I
have so far:
grant codeBase file:${catalina.home}/server/- {
permission java.lang.RuntimePermission *;
permission java.io.FilePermission ALL FILES,
read,write,delete;
permission java.util.PropertyPermission *, read,write;
permission java.security.SecurityPermission *;
permission java.net.SocketPermission *:0-,
accept,connect,listen,resolve;
permission java.net.NetPermission *;
permission java.io.SerializablePermission *;
permission org.apache.naming.JndiPermission *;
};
I've already removed the execute from the FilePermission and I've
left out the reflection permission since that's a really really ugly
one. Some of the above are probably way too broad... but certainly
no broader than AllPermission. I decided to start from the other
end of the spectrum and work backwards. With the above, I can still
run my own stuff and the tester stuff.
Incidentally, the tester webapp fails to initialize when the security
manager is enabled. Since it uses PropertyEditorManager in one of
its files, it requires PropertyPermission *, read,write in order
to run. I'm still trying to figure out how to enabled this just for
the tester app (I have it working if I stick it in the general grant
section). The docs in catalina.policy don't seem to be helping much.
The other curious thing about this particular error is that it doesn't
show up as an access failure when using the debugging built into the
security manager.
-Paul
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
