Use case for security managers/protection domains

[Mike Hearn]

Hello,

I noted that last month there was a brief discussion on security re:
modules, and Mark mentioned he didn't know of any compelling use cases for
the JDK security/permissions model outside of stuff like sandboxing applets
and the like.

Recently I've been pondering and researching a new use case for Java style
security management, which is to reduce code audit overheads for very
security sensitive apps. In particular, I work in the Bitcoin community,
and we are writing apps ("wallets") which control potentially large sums of
money and can move that money more or less instantly and irreversibly. This
fact makes attacking wallets by subverting the software development process
itself a potential problem.

Of course, whilst this issue is taxing the Bitcoin world first, it is
really an issue for any kind of cryptographic app that controls important
information.

So I've been research ways to fix this. One way is to have multi-signature
software updates. I've written a simple online update engine called
UpdateFX for javapackager-based JavaFX apps. The idea is multiple
developers all read the code commits since the last release, compile the
software from git head and verify they got the same JAR out, and then sign
it, and the update mechanism verifies that multiple signatures are present.
A single compromised developer cannot break the system.

The problem is that this only works when the software is fairly slow
moving. Otherwise developers find themselves in a bind: they must
potentially audit every line of code that is changed between every release
to detect an attempt to insert a back door. Including in dependent
libraries. This does not scale.

Java permissions to the rescue! A high security app can structure itself
with internal sandboxes around its sub-components. If the app "kernel"
manages the encryption keys and performs risk analysis or user
confirmations but little else, the rest of the app can be subjected to less
aggressive auditing. Potentially, the multi-signature requirement can be
relaxed for submodules. This would be ideal: the high security of an
audited, multi-signed app can be combned with the rapid iteration typical
of web apps.

I recognise that this is not an especially compelling use case* today* because
not many apps work this way. But I hope we will see it become more common
in future. Java 8 and JavaFX in particular are seeing some adoption in the
Bitcoin community because HTML5 doesn't really provide what we need to
build decentralised, secure applications. The flexible security model is a
cherry on top that we will hopefully start eating in the next 18-24 months.

thanks,
-mike