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, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
