What with the latest 0day getting a surprising amount of attention I figured I’d go ahead and show you guys my personal apparmor profile for Java, which I’ve only used a bit (I rarely run into the plugin online). I use this profile with Google Chrome on Ubuntu 12.04. It may require a few ‘tweaks’ depending on your specific setup and usage (see notes below) but for the most part this should work fine. If you have to add anything to it let me know – this should act as a helpful ‘base’ to start from though, I’ve covered the major things.
Notice that I don’t use any Cx. That means you can turn this profile into a child profile from your browser.
For a guide to write your own apparmor profile you can click here. I suggest you read that if you’re unfamiliar with apparmor – best to know what you’re getting into.
You can create the profile through:
# aa-autodep /usr/lib/jvm/java-7-oracle/jre/bin/java
And the profile itself:
# Last Modified: Sun Dec 9 01:46:38 2012
network inet stream,
network inet6 stream,
owner /home/** w,
owner /tmp/** m,
A few things are worth mentioning.
1) /tmp/** rw, could potentially become “/tmp/** r, owner /tmp/** w”. This shouldn’t break anything but I haven’t tested this. Just one more way to restrict it.
2) I use PaX and open source GPU drivers. I can’t really test Java with anything that uses GPU acceleration (it’s not supported with this drivers) so you may want to add: “ #include <abstractions/nvidia>”. Without quotes. This should give it access to some areas of the system that are more dangerous but allow for GPU acceleration. You can also manually add the locations by following my apparmor guide (posted earlier).
3) You can replace some version numbers (java-7-oracle) with a * (java-*-oracle) so that the profile works with all versions or at least should.
4) This isn’t perfect.
What Does This Do?
The benefits of running the Java plugin in Apparmor are numerous and revolve around keeping Java stuck in an environment where it only has access to what it legitimately needs to function. Just reading the profile it should be clear that it pretty much has access to some harmless font/ gtk files, its own files, and some slightly unruly read access to the /home/ directory.
So if I’m an attacker there are two things this is really stopping me from doing.
1) I can’t launch any second payloads, I can’t read a lot of sensitive information, and I can’t write to any critical parts of your system. It’s pretty crippled and anything not built specifically for a task like this (ie: NOT the one in the wild) is gonna break quickly.
2) I’m unable to gain access to a ton of information that could help me exploit the system further. Information on the file system can lead to ASLR information leaks or information on the system itself, giving attackers a big advantage if they want to locally exploit the system.
What it won’t stop is a payload that is built to work within the constraints of the profile. It’ll still stop it from reading/writing to a lot of dangerous places but a clever attacker could potentially work with the rights provided to them (network access, for example) to keylog the system or otherwise snoop. It just makes it way more difficult.