Security Warning from SLF4J on a Sandboxed Web Start App

I put together a small Java FX demo and packaged it as a sandboxed Web Start app.  The demo didn't access any resources that needed to be protected (OS, file system, cross domain networking calls). I had everything I needed in the signed JARs referenced in my JNLP.  Or so I thought.  It turns out that slf4j involves the network and will throw up a warning and greatly slow application startup.

The solution in my case was to dispense with logging altogether.  If you still would like to continue with logging, you can skip the slf4j interface and go work directly with Log4j.  It's the runtime search for slf4j bindings that is the problem.

Background

Web Start apps come in two security deployments: sandbox and all-permissions.  all-permissions warns that the program is about to be granted unlimited (or at least the OS limits put on your account) access to your system.  If you trust the source of the app, then you acknowledge the warning and carry on.  For the demo app I put together, I felt this was overkill and might dissuade someone from casually checking out the app while reading a blog post.

So, I specified "Permissions: sandbox" in the MANIFEST.MF of my app's JAR and also removed the <security> all-permissions tag in the copied JNLP that I was using.  (The default security setting is sandbox.)

When I uploaded and ran, the app took well over a minute to start up (compared with seconds in the IDE) and I received this warning.

Security Warning from Supposed Sandboxed App

Troubleshooting

After looking in the Java Console with a "v" (dump thread stack) I saw that the warning dialog was hung up on some slf4j code.  The code is repeated below with some println() statements that I put in.

Set<URL> staticLoggerBinderPathSet = new LinkedHashSet<URL>();
String STATIC_LOGGER_BINDER_PATH = "org/slf4j/impl/StaticLoggerBinder.class";
ClassLoader loggerFactoryClassLoader = LoggerFactory.class.getClassLoader();
Enumeration<URL> paths;

if (loggerFactoryClassLoader == null) {
  System.out.println("using system resourcse");
  paths = ClassLoader.getSystemResources(STATIC_LOGGER_BINDER_PATH);
} else {
  System.out.println("using user classloader");
  paths = loggerFactoryClassLoader.getResources(STATIC_LOGGER_BINDER_PATH);
}

if( paths != null ) {
  while( paths.hasMoreElements() ) {
    staticLoggerBinderPathSet.add(paths.nextElement());
  }
}

for( URL p : staticLoggerBinderPathSet ) {
  System.out.println( p );
}

After more trial-and-error, I traced the problem to a statement like this.

InetAddress addr = InetAddress.getByName( "https://www.bekwam.net" );

It turns out that in processing the Web Start URLs, there is a security check that is tripped.  I'm surprised because the URL mentioned in the dialog and in the sample code (https://www.bekwam.net) is the source of the download.

Download

The demo I'm writing about is a looping game background and can be launched from https://www.bekwam.net/background-sandbox/background.jnlp.

I've always thought that anything downloaded from the source was fair game.  Maybe it is and this is just a bug.  However, watch for networking security errors that might cause you punt on the sandbox and upgrade your app to an all-permissions.  You may be able to pull out the dynamic offender and still give your users the assurance that they're not compromising their systems.