Its the user's job to decide if allowing unsecured access to JMX Console is allowed under any circumstance - its not our job to deny such access without it being a configurable setting.

That said, we should at least spit out very loud warnings in the logs if we detect unsecured access outside of "localhost".

I think the solution to this is to:

log.warn("!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");
log.warn("!!!!! WARNING !!!!!!");
log.warn("! YOU ARE ALLOWING UNSECURED ACCESS TO JMX CONSOLE !");
log.warn("! PLEASE SEE http://jboss.com/SecureJBoss FOR MORE INFO !");
log.warn("!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");

The point of the change was to not be the source of the unsecure, globally available access. We were getting security exploit postings over this issue. Logging a message is not effective either.

Inconvience is the point. If your trying to access the server remotely, then you have to change something and the release notes document why localhost is the default. It was argued that it would be more inconvient to completely disallow access to the jmx console by configuring it to only configure users without valid permissions to access the consoles. The argument for localhost was that testsuites would not be broken, as well as allowing the typical localhost deployments used by developers.

My solutions:
a) Allow the user to only install via the installer. Here we can force the user to choose an admin /passwd.
b) Do not include the jmx-console/web-console anymore with the default distribution. Let it be an on-demand download with an installation notes mandating security of the consoles.

a) possibly. The testsuite setup would also need to run to lay down the default with security configured in accord with the testsuite.
b) would have to be all jmx invokers and this would also break the testsuite.

"ryan.campbell@jboss.com" wrote:
I'm skeptical that the existing approach will actually push users to read any documentation.

First of all, better don't make assumption about how users will react to the change. If jboss binds to 0.0.0.0 since year 1999 and now this has changed to localhost, I think this is already a big change and will at the very least make people wonder why's that. Release notes and blogging will help explain the problem, too.

Second, for the really naive users without any jboss knowledge that just unzip jboss, throw in a webapp, and they are done, or the case where a jboss server is installed by default and is just waiting there, unused, this measure offers some really basic but essential protection. Remember that we received negative comments about "remotely accessing a default jboss installation" and this is what we are fixing here.

From the point where somone starts messing with command line parameters and configuration options he/she must assume responsibility for his/hers doings.

I agree we can assist a user to create a more secure environment, but this is done either in the installer, or some post installation script. Besides, there are many points you need to secure, not just the jmx-console.

In my understanding, if we lock up everying in the default developer-oriented .zip distro, we'll just manage to enrage developers. And don't forget that the .zip distro IS primarily made for developers.

In a production environment where you'll have to make quite a few configuration changes before installing/testing/fine-tuning a server, securing the server is really one of the standard items in your checklist.

I'm pessimistic, too, in that creating a locked up static config will make more damage in our reputation for being developer friendly, than do good in our reputation for being unsecure.

And AFAIK. the user perception that we are "unsecure" came from a default installation. If you check the jboss forums people rarely complaint about an unsecure jboss - most of them know what they are doing.

There is so much you can do with a static configuration that needs to satisfy everyone. If there is no tools support for altering a jboss configuration at installation time, this is not a problem of the .zip distro. It's the problem of the tool.

I have just upgraded a system to the new Jboss Version.

We start this Jboss Instance with JbossService and now i'am wondering whereto give the parameter -b hostname.

I was thinking about bringing the b Option into the run.bat but i failed.

Do you have any sugestions.

greetz
wuschelz

Can anyone recommend a fix for wuschelz's question?

I've created a JBoss service using javaservice.exe and I've run into the same issue, where it only binds to the localhost address.

TIA

wuschelz, obshaffer,

Did either of you guys manage to figure out how to use the jboss service with the -b option?

Thanks,
Neil

This might help:

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss42FAQ