General security issue with tomcat, jboss (possibly other java ports)?

Jan Grant Jan.Grant at bristol.ac.uk
Sat Feb 12 03:31:16 PST 2005


Just noticed that the ports appear to install every tomcat, jboss4, etc, 
file under /usr/local with ownership www:www; these include the suid 
tomcat50ctl and jboss4ctl.

Since that's the user that the actual jboss, tomcat etc process are 
launched as (by default), the www user, that struck me as a little 
risky.

That's ok, though, because each of these come with a security policy:

[[
> cat /usr/local/jboss4/server/default/conf/server.policy
/// ====================================================================== ///
//                                                                          //
//  JBoss Security Policy                                                   //
//                                                                          //
/// ====================================================================== ///

// $Id: server.policy,v 1.4 2003/08/27 04:31:53 patriot1burke Exp $

grant {
   // Allow everything for now
   permission java.security.AllPermission;
};
]]

In short, in the spirit of defence in depth, I think more careful use of 
unix file permissions should be made when installing this software: that 
is, root:wheel (as is common elsewhere throughout the ports-installed 
stuff: eg, apache2, which commonly runs as the www:www user). This is 
especially the case with a server like jboss which permits the dynamic 
uploading and deployment of new services.

Whilst we're at it, I was under the impression that www:www was intended 
to be a web-process-only (or apache-only) user/group - that is, that 
only web servicing processes should be in the www group. Looking at 
jboss4ctl, tomcat50ctl, it appears that these ports extend the semantics 
of the www group to include "users who should be able to control these 
web processes". It's not difficult to add a second wwwctl, tomcat50ctl, 
jboss4ctl, etc group and have the *ctl utilities honour that group 
membership instead: or alternatively, to simply follow the apache port 
and require root privileges (or appropriate sudo configuration) to 
control this server port. Indeed, it's not quite clear why the tomcat, 
jboss etc. ports reuse this user and group when the creation of new ones 
is pretty trivial.

It's worthwhile pointing out that the security issues with having the 
jboss stuff in www:www work in the other direction, too: a compromise of 
(say) a PHP script under apache would permit the modification of the 
jboss startup scripts in /usr/local/jboss4/bin.

If it's simpler I can file a PR with this; thought Id just raise it here 
first, though, since the fixes are generally pretty straightforward, and 
I might have missed an obvious reason for doing things this way.

Cheers,
jan

-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287864 or +44 (0)117 9287088 http://ioctl.org/jan/
"...perl has been dead for more than 4 years." - Abigail in the Monastery




More information about the freebsd-java mailing list