Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Java is still the most secure widespread runtime

Andrew C. Oliver | Feb. 1, 2013
Or why I don't care about the Java flaw. Are you a big Swing user? Excited over JavaFX on multiple platforms? Me neither.

The recent Java bug is in the SecurityManager. In other words, the hole threatens mainly applets or Web-delivered Java fat clients. I generally don't enable that stuff because little I use on the Internet can't live without it.

You probably know the SecurityManager as Java's "sandbox" introduced with Sun's marketing of Java Applets. It also has uses on the server. The SecurityManager is essentially Java's equivalent of SELinux or AppArmor, although it predates both. It tells Java which class can execute which "risky" functions (such as accessing the file system). You can implement a more coarse-grained version of much the same on a process level with Unix file permissions, the aforementioned AppArmor/SELinux, or a combination of technologies.

Some Java desktop applications like the Eclipse IDE are rarely Web-delivered and rarely even run in the SecurityManager. In other words, they're unaffected.

The people who will be most affected are Swing users, due to a few widespread applications dependent on client-side Java. Me, the only thing I use is WebEx. I keep a separate browser installed that I fire up only for WebEx.

The bug reduces some options for Java multitenancy (running applications from multiple providers in one JVM), but most multitenanted environments do not depend on a single JVM, using virtualization technologies instead.

Two years until a fix? Not likely
The press has quoted some security expert as saying it will take two years to fix the Java SecurityManager. This isn't strictly true; the known exploit is patched. What's really meant here, on closer inspection, is that the SecurityManager couplings are a complicated mess. In other words, they were written by Sun.

While it may take two years to fully deploy a completely redesigned security subsystem for Java, I can't imagine it will take two whole years to fix. Folks have completely implemented the JVM and APIs in less than that time. However, if this is tied to a major release like Java 8, we're talking two years easy to be fully deployed. Moreover, as it stands, this will likely break compatibility for the people most affected (people who still using Swing, for example). Seeing that many of these applications are "dead code," haven't been updated in a while, and were broken by Java 7, the fix probably will come too late to save the long tail of client-side Java.


1  2  Next Page 

Sign up for CIO Asia eNewsletters.