If you use JBoss and have a nicely secured JMX Console and/or Web Console it’s a fairly safe bet that, like me, you haven’t secured the invoker layer; meaning any old monkey can most likely shutdown your container whenever they feel like it.
Recently I implemented an MBean in JBoss to use as a batch trigger from a ControlM implementation and was surprised (probably shouldn’t have been though) that all my carefully crafted security for the JMXConsole and Web Console was ignored with complete impunity by the tool (twiddle.sh) that I used to invoke my MBean. Since then I’ve been through a pile of pain trying to get an RMI call to a JBoss XMBean to require authentication and I thought I’d put some instructions in plain language on how to do it.
I do this for two reasons:
- because I bet a lot of developers miss this one; and
- because the documentation and other information I find online is limited and confusing.
For demonstration I’m going to use a standard JBoss MBean for setting system properties in a running application container.
A Simple Example of Setting a System Property in JBoss using Twiddle
Using the default JBoss version of twiddle.sh (in the bin directory beneath JBoss home) against the default JNP location of JBoss (localhost:1099) you can execute the following to set a system property in a running container.
# this assumes you're in the bin directory of JBoss Home.
./twiddle.sh -s localhost:1099 invoke "jboss:type=Service,name=SystemProperties" set myprop mypropvalue
'null'
To verify that you have been succesful (assuming you didn’t get an exception in the last operation) you can do the following:
# this assumes you're in the bin directory of JBoss Home.
./twiddle.sh -s localhost:1099 invoke "jboss:type=Service,name=SystemProperties" get myprop
mypropvalue
This example will work from anywhere on your network where you’re not prevented from reaching the JNP URL of the container (prevented by a firewall or IP filter for example) regardless of the JMX Console and Web Console security you’ve put in place (there is plenty of documentation around for securing the JMX Console and Web Console). This is because the JMX Console and Web Console are HTTP based and as such are secured in the normal way you would secure a website on JBoss (i.e. in web-inf.xml and jboss-web.xml) whereas the invoker layer is not HTTP based and as such must use an alternate method of security; the key file in this operation is the jmx-invoker-service.xml file in the JBoss deploy directory.
Securing the Invoker Layer
The invoker layer is the one you are calling through when you query or invoke on an MBean via RMI (i.e. with twiddle.sh – as above). This layer is not subject to the security constraints you will have placed on your HTTP based JMX Console or Web Consoles.
To make this layer secure the key file you’re interested in is the jmx-invoker-service.xml in the JBoss deploy directory; and the key operation configuration you will need to change is for ‘invoke’.
The default configuration of the invoke operation in this file is:
<server>
<!-- excluded for brevity -->
<mbean code="org.jboss.jmx.connector.invoker.InvokerAdaptorService" name="jboss.jmx:type=adaptor,name=Invoker" xmbean-dd="">
<xmbean>
<description>The JMX Detached Invoker Service</description>
<class>org.jboss.jmx.connector.invoker.InvokerAdaptorService</class>
<!-- excluded for brevity -->
<operation>
<description>The detached invoker entry point</description>
<name>invoke</name>
<parameter>
<description>The method invocation context</description>
<name>invocation</name>
<type>org.jboss.invocation.Invocation</type>
</parameter>
<return-type>java.lang.Object</return-type>
<descriptors>
<interceptors>
<!-- Uncomment to require authenticated users -->
<!-- <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/> -->
<!-- Interceptor that deals with non-serializable results -->
<interceptor code="org.jboss.jmx.connector.invoker.SerializableInterceptor" policyClass="StripModelMBeanInfoPolicy"/>
</interceptors>
</descriptors>
</operation>
</xmbean>
</mbean>
</server>
So to switch on authentication we do what it says and ‘Uncomment to require authenticated users’:
<server>
<!-- excluded for brevity -->
<mbean code="org.jboss.jmx.connector.invoker.InvokerAdaptorService" name="jboss.jmx:type=adaptor,name=Invoker" xmbean-dd="">
<xmbean>
<description>The JMX Detached Invoker Service</description>
<class>org.jboss.jmx.connector.invoker.InvokerAdaptorService</class>
<!-- excluded for brevity -->
<operation>
<description>The detached invoker entry point</description>
<name>invoke</name>
<parameter>
<description>The method invocation context</description>
<name>invocation</name>
<type>org.jboss.invocation.Invocation</type>
</parameter>
<return-type>java.lang.Object</return-type>
<descriptors>
<interceptors>
<!-- Uncomment to require authenticated users -->
<interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
<!-- Interceptor that deals with non-serializable results -->
<interceptor code="org.jboss.jmx.connector.invoker.SerializableInterceptor" policyClass="StripModelMBeanInfoPolicy"/>
</interceptors>
</descriptors>
</operation>
</xmbean>
</mbean>
</server>
If you haven’t changed the default security realm for your JMX Console (i.e. java:/jaas/jmx-console) you will now have an invoker layer secured with the same credentials as for your JMX Console. To change this add a new security realm to your global login-config.xml in the conf directory of your container and match the name you give it in the securityDomain attribute of the Authentication Interceptor.
I’ve not yet delved too deeply into setting a specific set of roles, at this point I set my invoker user to JBossAdmin which means that user can do pretty much anything exposed to JMX. That’s ok for my purposes tho (feel free to write a response with the details of setting roles for particular JMX functions 
).
Invoking on a Secure Invoker Layer
Ok so now that it’s secure how do you invoke an operation on it?
With the default JBoss twiddle.sh utility there are arguments -u (or –user=) for user and -p (–password=) for password.
# this assumes you're in the bin directory of JBoss Home.
./twiddle.sh -s localhost:1099 --user=myuser --password=mypassword invoke "jboss:type=Service,name=SystemProperties" get myprop
mypropvalue
These arguments work fine except your password is now in clear text and even worse is visible in the process list while it’s executing – in clear text with ‘password=’ conveniently placed for extraction by a simple script!! This seems a bit of an oversight in the tool to me.
To get around this issue in my environment I took the source and modified the main class of twiddle.jar to accept a password from Standard In (patch is below – no promises or guarantees though) which prevents the password showing in your password list and allows you to use standard encryption utilities to decrypt and pipe it into the process without ever making it visible clear text.
You would now invoke as follows:
# this assumes you're in the bin directory of JBoss Home.
mypassword | ./twiddle.sh -s localhost:1099 --user=myuser invoke "jboss:type=Service,name=SystemProperties" get myprop
mypropvalue
or better; from an encrypted password file (or better yet a repository) such as follows:
# this assumes you're in the bin directory of JBoss Home and have previously encrypted your password and encryption key into ~/.<username>.key and ~/.<username>.psw.
KEY=`cat ~/.<execution username>.key`
PWD=`cat ~/.<execution username>.psw | crypt $KEY`
PWD | ./twiddle.sh -s localhost:1099 --user=myuser invoke "jboss:type=Service,name=SystemProperties" get myprop
mypropvalue
to encrypt your password to be used as above you might do:
echo "<password>" | crypt > ~/.<execution username>.psw
which will request an encryption key which you would save as follows (for this example anyway):
cat "<encryption key>" > ~/.<execution username>.key
These files would, of course, be accessable only from your execution user.
Securing the JMX Console
For reference the key files you’re interested in here are:
- conf/login-config.xml
- deploy/jmx-console.war/META-INF/web.xml
- deploy/jmx-console.war/META-INF/jboss-web.xml
Securing the JMX Web Console
For reference the key files you’re interested in here are:
- conf/login-config.xml
- deploy/management/web-console.war/META-INF/web.xml
- deploy/management/web-console.war/META-INF/jboss-web.xml
Stack
These instructions will apply broadly but for reference purposes the stack I have is:
- JBoss 4.2.3.GA
- Java jdk1.6.0_13
- Windows XP or Solaris 10
References
http://www.jboss.org/community/wiki/Twiddle
http://www.jboss.org/community/wiki/jbossserver-aquicktour
https://jira.jboss.org/jira/secure/attachment/12313982/jboss-securejmx.pdf (PDF Document)
Regards,
Jon
Patch For Twiddle to Take Password from StdIn (no promises or guarantees)
Index: src/main/org/jboss/console/twiddle/Twiddle.java
===================================================================
--- src/main/org/jboss/console/twiddle/Twiddle.java (revision 94201)
+++ src/main/org/jboss/console/twiddle/Twiddle.java (working copy)
@@ -24,8 +24,10 @@
import gnu.getopt.Getopt;
import gnu.getopt.LongOpt;
+import java.io.BufferedReader;
import java.io.File;
import java.io.InputStream;
+import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.MalformedURLException;
import java.net.URL;
@@ -41,7 +43,6 @@
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
-
import org.jboss.console.twiddle.command.Command;
import org.jboss.console.twiddle.command.CommandContext;
import org.jboss.console.twiddle.command.CommandException;
@@ -148,7 +149,7 @@
}
};
}
-
+
public Command createCommand(final String name)
throws NoSuchCommandException, Exception
{
@@ -383,7 +384,7 @@
out.println("A JMX client to 'twiddle' with a remote JBoss server.");
out.println();
- out.println("usage: " + PROGRAM_NAME + " [options] <command> [command_arguments]");
+ out.println("usage: [echo <password> | ] " + PROGRAM_NAME + " [options] <command> [command_arguments]");
out.println();
out.println("options:");
out.println(" -h, --help Show this help message");
@@ -397,6 +398,10 @@
out.println(" -u, --user=<name> Specify the username for authentication");
out.println(" -p, --password=<name> Specify the password for authentication");
out.println(" -q, --quiet Be somewhat more quiet");
+ out.println();
+ out.println("A password should be passed in by echoing it and piping it to the command. If you");
+ out.println("use the -p (--password) option your password may be visible in clear text in a ");
+ out.println("process listing such as `ps -ef`.");
out.flush();
}
@@ -421,6 +426,28 @@
Getopt getopt = new Getopt(PROGRAM_NAME, args, sopts, lopts);
int code;
+ /* Get standard in if it's there - assume it's a password. This is to allow a password to be passed and
+ * prevent it showing in a process listing (e.g. ps -ef in Unix). The -p argument will be ignored if
+ * the password is passed through Standard In.
+ */
+ boolean passwordRetrievedFromStdIn = false;
+ if (System.in.available() > 0) {
+ InputStreamReader inp = new InputStreamReader(System.in);
+ BufferedReader br = new BufferedReader(inp);
+ String stdin = br.readLine();
+
+ if (stdin != null && stdin.trim().length() > 0) {
+ String password = stdin.trim();
+ SecurityAssociation.setCredential(password);
+
+ passwordRetrievedFromStdIn = true;
+
+ if (log.isDebugEnabled()) {
+ log.debug("Password retrieved from standard in. Ignoring -p argument.");
+ }
+ }
+ }
+
PROCESS_ARGUMENTS:
while ((code = getopt.getopt()) != -1)
@@ -531,8 +558,13 @@
SecurityAssociation.setPrincipal(new SimplePrincipal(username));
break;
case 'p':
- String password = getopt.getOptarg();
- SecurityAssociation.setCredential(password);
+ if (!passwordRetrievedFromStdIn) {
+ String password = getopt.getOptarg();
+ SecurityAssociation.setCredential(password);
+
+ log.warn("Password retrieved from -p argument. Your password may be visible in cleartext in a process listing during execution. " +
+ "Consider using Standard In to enter the password instead (i.e. echo \"password\" | twiddle ...)");
+ }
break;
// Enable quiet operations
Chris Burnley
Chris Clark
Jon Court
