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