Sandboxing: Conclusion

In total I’ve written five methods for sandboxing code. These are certainly not the only methods but they’re mostly simple to use, and they’re what I’ve personally used.

A large part of this sandboxing was only possible because I built the code to work this way. I split everything into privileged and unprivileged groups, and I determined my attack surface. By moving the sandboxing after the privileged code and before the attack surface I minimized risk of exploitation. Considering security before you write any code will make a very big difference.

One caveat here is that SyslogParse can no longer write files. What if, after creating rules for iptables and apparmor, I want to write them to files? It seems like I have to undo all of my sandboxing. But I don’t – there is a simple way to do this. All I need is to have SyslogParse spawned by another privileged process, and have that process get the output from SyslogParse, validate it, and then write that to a file.

One benefit of this “broker” process architecture is that you can actually move all of the privileged code out of SyslogParse. You can launch it in another user, in a chroot environment, and pass it a file descriptor or buffer from the privileged parent.

The downside is that the parent must remain root the entire time, and flaws in the parent could lead to it being exploited – attacks like this should be difficult as the broker could would be very small.

Hopefully others can read these articles and apply it to their own programs. If you build a program with what I’ve written in mind it’s very easy to write sandboxed software, especially with a broker architecture. You’ll make an attacker miserable if you can make use of all of this – their only real course of action is to attack the kernel, and thanks to seccomp you’ve made that a pain too.

Before you write your next project, think about how you can lock it down before you start writing code.

If you have anything to add to what I’ve written – suggestions, corrections, random thoughts – I’d be happy to read comments about it and update the articles.

Here’s a link to all of the articles:

Seccomp Filters:

Linux Capabilities:

Chroot Sandbox:


And here’s a link to the GitHub for SyslogParse:

Sandboxing: Apparmor

Sandboxing: Apparmor

This is the fifth installment on a series of various sandboxing techniques that I’ve used in my own code to restrict an applications capabilities. You can find a shorter overview of these techniques here. This article will be discussing sandboxing with Apparmor.

Mandatory Access Control:

Mandatory Access Control (MAC), like Discretionary Access Control (DAC), is meant to define permissions for a program. Users and Groups are DAC. But what if you want to confine a program with full root? As discussed, root with full capabilities is quite dangerous – and in the case of SyslogParser quite a few of those capabilities are necessary.

Apparmor is a form of Mandatory Access Control implemented through the Linux Security Module hooks in the Linux kernel. MAC is “administrator” defined policy, and can confine even root applications.

Apparmor is a *bit* out of scope for this series, as it doesn’t actually involve any code, but it’s still relevant.

The Code:

While Apparmor itself doesn’t have code in SyslogParse, here’s the profile for the program.

# Last Modified: Wed Aug 13 18:57:15 2014


/usr/bin/syslogparse mr,
/var/log/* mr,

/etc/ mr,

/sys/devices/system/cpu/online r,

/lib/@{multiarch}/* mr,
/lib/@{multiarch}/libc-*.so mr,
/lib/@{multiarch}/libm-*.so mr,
/lib/@{multiarch}/libpthread*.so mr,

/usr/lib/@{multiarch}/* mr,
/usr/lib/@{multiarch}/libcap-ng*.so* mr,

/usr/lib/@{multiarch}/libstdc*.so* mr,


Apparmor is incredibly straight forward. There is a path, and then there is one or more letters. These letters stand for certain things.

r = read
m = map
w = write

All of this is pretty straight forward. SyslogParse gets the number of CPU cores from /sys/devices/system/cpu/online , so it needs “r” access.

It needs to read some libraries in order to function.

And that’s it. Sort of… apparmor on my system is, unfortunately, quite broken. The tools for enforcing/ complaining crash on me (I have a lot of weird profiles that I experiment with), which is actually why I started building SyslogParse. So this profile is a bit incomplete. It still needs some capabilities defined for chroot, setuid/setgid, and possibly more file access.


When enabled an Apparmor profile will begin enforcing policy as soon as the process begins. That means that, even if running as root, an attacker is always confined to those files defined in the profile. Apparmor is quite powerful, and combined with the other sandboxing techniques used it’s a very nice reinforcement – writing to the chroot, for example, is denied throughout the process by both DAC and MAC now.

Apparmor is, unfortunately, only available on certain distributions.

Next Up: Final Conclusion

Apparmor Profile For DNSCrypt

DNSCrypt is a program that provides encryption for DNS requests. I have a guide for setting it up here and a guide for locking it down further here.

This is a short apparmor profile for the program. I’ve removed all abstractions, and it works for me.

# Last Modified: Sat Jul 6 02:21:04 2013
# This Apparmor profile is provided by , and if there are updates that # is where you will find them. Report
# issues or changes there please!

#include <tunables/global>

/usr/local/sbin/dnscrypt-proxy {

network inet stream,
network inet6 stream,
network inet dgram,
network inet6 dgram,

capability block_suspend,
capability net_admin,
capability net_bind_service,
capability setgid,
capability setuid,
capability sys_chroot,

/usr/local/lib/* mr,

/bin/false r,
/dev/null rw,
/dev/urandom r,
/etc/ r,
/etc/localtime r,
/etc/nsswitch.conf r,
/etc/passwd r,
/lib/*-linux-gnu*/libc-*.so mr,
/lib/*-linux-gnu*/libm-*.so mr,
/lib/*-linux-gnu*/libnsl-*.so mr,
/lib/*-linux-gnu*/libnss_compat-*.so mr,
/lib/*-linux-gnu*/libnss_files-*.so mr,
/lib/*-linux-gnu*/libnss_nis-*.so mr,

/usr/lib/* mr,
/usr/local/lib/* mr,

/usr/lib/* mr,


The dnscrypt-proxy service can run as a separate user, and chroot itself into the directory and drop rights. It also makes use of compiler security flags, so it’s PIE enabled, uses full RELRO, and stack protection. It’s pretty cool, but I like to be sure, so enforcing an apparmor profile is always nice.

With this apparmor profile enabled an attacker who compromises DNSCrypt will have absolutely no write access to the file system, and incredibly limited read access. The most viable option at this point is for them to go for a local kernel exploit.


Hardening Ubuntu Linux

I’m going to keep some tips here for users looking to improve their security, when I update it I’ll tweet about it, so feel free to follow me @insanitybit. This is aimed at desktop users but naturally lots of it can apply to a Linux server. Some of this will be simple, trivial, and some of this will be quite a bit more difficult. I’m focusing specifically on Ubuntu but other distros will have similar features (replace Apparmor with SELinux). I will try to make this as comprehensive as possible, though I’m specifically avoiding items like Fail2Ban as it’s not really useful for users. You can consider this an extension of my ‘definitive guides‘ – The Definitive Guide For Securing Linux Ubuntu.

A lot of users believe that a distro such as Ubuntu will be so much more secure than Windows, purely through virtue of obscurity. As Linux popularity continues to grow you’ll see attackers begin to take notice. Just because attackers don’t care to hack Linux desktop systems does not by any means imply they aren’t capable of it, or ready to when it seems profitable.

Thankfully, Linux is really easy to secure. Despite some problems there are a lot of powerful projects that give users the power to secure themselves against many threats.

Securing Your Browser

First I’d like to start by linking to my guides for locking down Chrome and Firefox As a user your most exploitable area is your browser, it’s constantly taking in untrusted content, often over an insecure connection. I personally love Chrome’s Linux sandbox, but Firefox with NoScript is very powerful as well – I leave it to you to decide between the two based on your needs.

Enabling Ubuntu’s Firewall

Ubuntu comes with a firewall utility called UFW, but it isn’t enabled by default. The reason is that, by default, Ubuntu doesn’t have any open ports open (except for system services that are typically necessary for the average user). So is a Firewall strictly necessary? Well, if you’re behind a NAT router not so much, any open ports will expose you to local attacks, but you’re ‘hidden’ from the internet. Still, if you’re looking to secure your system you can simply run this command:

ufw enable

ufw default deny incoming

And it should prevent inbound access. You can create complex rules via iptables to restrict or relax your rules. You can also check out GUFW for a graphic interface to UFW. GUFW makes everything very easy to use.

You can use UFW/GUFW to create outbound rules for applications. Due to the amount that applications within a user ID can interfere with one another I do not feel that an outbound firewall is worthwhile for security, and it can be quite a bit of a pain. If you’re serious about setting up an outbound firewall I suggest you make strict use of user separation and apparmor, though even then the benefits are questionable (there is a reason programs like Comodo on Windows bundle their firewall components with strict HIPS software).

See this guide for further information on setting up firewalls. Courtesy of a very smart guy, Dangertux.

Run a Program As A Separate User

While the simplest way to restrict a program is AppArmor (see below) you can also make use of the native user/group Linux permissions in order to run an application as a different user. I’ve written a guide with Pidgin as the example. Separated programs will have less access to one another and they’ll live in a different user directory, with access only to that directory.

By separating a program to a new user we can also write more powerful firewall rules, as the program won’t be able to bypass an outbound rule as trivially.

For a risky program that doesn’t need to access other programs this may be a very viable option. For example, I run Xchat, which hasn’t been updated in about two years. For a program like this throwing as much security as possible at it isn’t a bad idea, since it doesn’t get patches, doesn’t use modern security techniques, and is internet facing.

Restricting DMESG

By default unprivileged users can read a lot of your systems logs. These logs can contain critical information for an attacker hoping to exploit your system further.

This is useful for debugging, but you’re not likely to have to do that. Running this command will prevent access by unprivileged users:

echo kernel.dmesg_restrict = 1 >> /etc/sysctl.conf

This feature is also included in the Grsecurity patch.


DNSCrypt is a DNS resolver that encrypts the content of your request between you and the first level resolver. It prevents an attacker from hijacking or viewing your DNS resolution and the program itself is hardened quite a lot.

For a guide to install.

For a guide to harden further.

Removing Attack Surface

One of the first steps to harden any operating system should always be disabling unnecessary programs/ services. Desktop operating systems don’t come “default secure” they come “default compatible” and that means meeting the needs of every person, generically. So while John may use his network printer Jane may not, but Jane’s system still comes with all of the attack surface necessary for network printing.

The network printing service is cupsd. It comes, by default, in an Apparmor profile, so it’s not like you should be incredibly worried about being exploited. And if you’re behind NAT you’re only exposed to local attacks. But, if you’re like me, you don’t print over a network and you have no need for this service. Are you likely to be attacked over it? Maybe, maybe not, but it’s not needed. So go ahead and remove that service.

You can check for programs listening on your system with the following command:

netstat -tulnp

Look up any services and carefully consider the benefit/ necessity of them. If you don’t need them or want them, remove them.

Another tip is to use Run the following command: (You must first set the file as executable)

./ –proc-all

It will provide you with a list of running services along with information about their security – whether they use NX, stack canaries, and if they’ve been compiled as Position Independent Executables (PIE). This may help you make a more informed decision about removing a service.

Mount /tmp With noexec,nodev,nosuid

Many programs require read/write access to /tmp but, for the most part, no programs actually need to be able to execute from there. Mounting this area with the noexec, nodev, nosuid can provide some level of security. Rather than creating a new partition for /tmp I find it’s just easier to use RAM (it expands as needed and doesn’t require partitioning , one benefit being a (potential) performance increase, though I wouldn’t bet on it.

Copy the following into your /etc/fstab file.

tmpfs /tmp tmpfs mode=1777,nosuid,nodev,noexec 0 0

If you want to create a new partition for /tmp you can find a guide online for that. It’s kinda a pain. The downside to running it in RAM is, obviously, you lose some RAM. If you want to limit the amount of RAM it can use (tmpfs expands as needed) you can change the line to (for 512M):

tmpfs /tmp tmpfs size=512M,mode=1777,nosuid,nodev,noexec 0 0

I recommend that if you follow the above you make use of AppArmor to improve the level of security this adds. If you use /tmp in RAM one benefit is that, in your AppArmor profiles, you should be able to remove map rules for some programs that map /tmp for performance reasons.


AppArmor is the Linux Security Module of choice for Ubuntu. It implements Mandatory Access Control on a per-process basis. It’s very simple to learn how to use AppArmor and I’ve written a guide. In the guide I provide tips for creating strong AppArmor profiles and avoiding potential pitfalls.

A program like Pidgin has a lot of access to your system. It runs as the same user as many other programs on your system and therefor is granted a fair amount of control over them. It can read many areas of the system that it doesn’t need to read, it can write to quite a few too. AppArmor restricts it to only the resources it needs, making both remote and local privilege exploits more difficult to pull off.

I’ve written a few very strict AppArmor profiles myself that you’re welcome to use as a starting point. [Xchat][Pulseaudio] [Java]

32bit users will have to adjust as needed, though it should be as simple as replacing the x86_64 with i386 (I’ll add variables for this at some point so you won’t have to).

Every internet facing program deserves an AppArmor profiles. It’s the simplest way to implement least privilege on a per application basis.

PaX and Grsecurity

PaX and Grsecurity are patches for the Linux kernel (the Grsecurity patch contains both, don’t just use PaX). PaX and Grsecurity have been at the forefront of security for more than a decade, bringing some of the most important security mitigation techniques to systems today, such as Address Space Layout Randomization (ASLR). ASLR is a great example of a mitigation technique that doesn’t have a great implementation in typical vanilla systems. The ASLR in your average distro, like Ubuntu, introduces far less entropy into the system, which degrades its use. The ASLR is also missing critical features, such as brute force deterrence, among others. PaX and Grsecurity bring these features and many many others to Linux. No operating system has as complete ASLR as PaX and, really, nothing else compares.

Not all of these features are compatible for desktop users, or even necessary, but a number of them will work on an Ubuntu desktop. You can see my guide for patching and compiling a Grsecurity Linux kernel, with notes about compatibility issues for desktop users.

Many of these security features directly relate to desktop security. Many applications and services use chroot to run programs in a separate environment. Chroot is incapable of restricting programs that can run as root, multiple bypasses are possible. Chrome is one such program, along with many other services (like avahi-daemon), so using the chroot hardening features of Grsecurity will provide a considerably more secure environment.

PaX and Grsecurity can be implemented with very little performance overhead, and very few stability issues if configured properly. If you’re really looking to secure your Linux system and you’re willing to take the time to compile it you should give it a try.

Learn how to compile your own Grsecurity Linux kernel here.


None of the above will make up for a system that is out of date and unpatched. If you’re using an older kernel and userland applications an attacker will be able to chain together enough exploits to bypass any restrictions/ measures you’ve taken, no matter how powerful. Make sure to stay up to date for all applications.

You can push patch time further by hardening the system – time to develop an exploit for a hardened system is longer. This does not mean you can postpone indefinitely, it just buys you time to test patches and improve your patch management.

Something To Keep In Mind

This all works best in conjunction. Grsecurity and PaX are honestly the best security software there is, in my opinion, but they can’t make up for a completely insecure userland. If you’re running programs that opt out or don’t make use of modern technology there’s only so much they can do. It’s very unfortunate but, even on 64bit, Ubuntu ships with a lot of services not using Position Independent Executable code – at this point it’s necessary to harden the programs in other ways.

And the same goes both ways. If you’re not using Grsecurity and PaX then your kernel is less secure, meaning that even if you harden a userland application with apparmor an attacker will have a much easier time exploiting the kernel and escaping the profile.

If you’re annoyed about your distro coming with insecure settings email them about it. You can reach Canonical:

 you have suggestions for or, please email us or

And if you have any suggestions for this guide please let me know in a comment. I’ll happily include any relevant information.

Follow me @insanitybit for updates and more articles like this.

AppArmor Profile For Pulseaudio

Pulseaudio is an application used on many Linux systems to handle audio. It isn’t PIE, so it’s not a bad idea to restrict it. I believe Fedora uses an SELinux profile for Pulseaudio, but as an Ubuntu user I’m left having to make an AppArmor profile for it. If you’ve been reading my blog you’ll know that AppArmor is a Mandatory Access Control system used by default by Ubuntu, among other Linux distributions. Restricting programs with AppArmor limits potential damage of vulnerabilities in those programs.

This profile works on my 64bit Ubuntu system. I’ll keep it updated here in case something changes, but I’m watching video via Chrome just fine. It’s obviously not a very strong AppArmor profile as Pulseaudio starts off running with very high rights/ capabilities, but we can at least somewhat limit file access. I’m going to try to limit lib access further, but for now this is something.

I’ll update this as needed, but as it is things should work smoothly. Follow me @insanitybit for consistent updates.

The profile:

# Last Modified: Tue Apr 16 18:22:57 2013
#include <tunables/global>

/usr/bin/pulseaudio {
capability chown,
capability dac_override,
capability fowner,
capability fsetid,
capability kill,
capability setgid,
capability setuid,
capability sys_nice,
capability sys_ptrace,
capability sys_resource,


/dev/null rw,
/dev/random r,
/dev/snd/controlC* rw,
/dev/snd/pcm* rw,
/dev/urandom r,
/etc/group r,
/etc/ r,
/etc/locale.alias r,
/etc/localtime r,
/etc/nsswitch.conf r,
/etc/passwd r,
/etc/pulse/client.conf r,
/etc/pulse/daemon.conf r,
/etc/pulse/ r,
/etc/pulse/ r,
/etc/udev/udev.conf r,
/home/*/.ICEauthority r,
/home/*/.Xauthority r,
/home/*/.config/pulse/ rw,
/home/*/.config/pulse/* rwk,
/home/*/.esd_auth rwk,
/home/*/.pulse-cookie rwk,
/home/*/.pulse/ rw,
/home/*/.pulse/* rw,
/home/*/orcexec.* rw,
/lib/x86_64-linux-gnu/libc-*.so mr,
/lib/x86_64-linux-gnu/* mr,
/lib/x86_64-linux-gnu/libdbus-*.so.* mr,
/lib/x86_64-linux-gnu/libdl-*.so mr,
/lib/x86_64-linux-gnu/libglib-*.so.* mr,
/lib/x86_64-linux-gnu/* mr,
/lib/x86_64-linux-gnu/libm-*.so mr,
/lib/x86_64-linux-gnu/libnsl-*.so mr,
/lib/x86_64-linux-gnu/libnss_compat-*.so mr,
/lib/x86_64-linux-gnu/libnss_files-*.so mr,
/lib/x86_64-linux-gnu/libnss_nis-*.so mr,
/lib/x86_64-linux-gnu/* mr,
/lib/x86_64-linux-gnu/libpthread-*.so mr,
/lib/x86_64-linux-gnu/libresolv-*.so mr,
/lib/x86_64-linux-gnu/librt-*.so mr,
/lib/x86_64-linux-gnu/* mr,
/lib/x86_64-linux-gnu/* mr,
/lib/x86_64-linux-gnu/* mr,
/lib/x86_64-linux-gnu/* mr,
/lib/x86_64-linux-gnu/* mr,
/proc/*/mounts r,
/proc/asound/card*/ r,
/proc/asound/card*/pc*/ r,
/proc/asound/card*/pc*/sub*/ r,
/proc/asound/card*/pc*/sub*/status r,
/proc/cpuinfo r,
/proc/filesystems r,
/proc/stat r,
/proc/sys/kernel/ngroups_max r,
/root/.esd_auth rwk,
/root/.pulse-cookie rw,
/root/.pulse/ rw,
/root/.pulse/* rw,
/run/pulse/ rw,
/run/pulse/.pulse-cookie rwk,
/run/pulse/dbus-socket rwk,
/run/pulse/native rwk,
/run/pulse/pid rwk,
/run/shm/ r,
/run/shm/* rw,
/run/udev/data/*sound:card* r,
/run/user/*/pulse/ rw,
/run/user/*/pulse/* rwk,
/run/user/lightdm/ rw,
/run/user/lightdm/pulse/ rw,
/run/user/lightdm/pulse/* rwk,
/sys/bus/ r,
/sys/class/ r,
/sys/class/sound/ r,
/sys/devices/pci[0-9]*/**/*class r,
/sys/devices/pci[0-9]*/**/uevent r,
/sys/devices/system/cpu/ r,
/sys/devices/system/cpu/online r,
/sys/devices/virtual/dmi/id/bios_vendor r,
/sys/devices/virtual/dmi/id/board_vendor r,
/sys/devices/virtual/dmi/id/sys_vendor r,
owner /tmp/** mrwk,
/usr/bin/pulseaudio mrix,
/usr/lib/ r,
/usr/lib/libpulse*.so* mr,
/usr/lib/locale/locale-archive r,
/usr/lib/pulse-*/modules/*.so* mr,
/usr/lib/pulseaudio/pulse/gconf-helper rix,
/usr/lib/x86_64-linux-gnu/alsa-lib/* mr,
/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/libgconf-*.so.* mr,
/usr/lib/x86_64-linux-gnu/libgio-*.so.* mr,
/usr/lib/x86_64-linux-gnu/libgmodule-*.so.* mr,
/usr/lib/x86_64-linux-gnu/libgobject-*.so.* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/liborc-*.so.* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/* mr,
/usr/lib/x86_64-linux-gnu/pulseaudio/lib*-*.so* mr,
/usr/share/alsa/** r,
/usr/share/applications/ r,
/usr/share/applications/* r,
/usr/share/pulseaudio/** r,
/var/lib/dbus/machine-id r,
/var/lib/lightdm/.Xauthority r,
/var/lib/lightdm/.config/pulse/ rw,
/var/lib/lightdm/.config/pulse/* rwk,
/var/lib/lightdm/.esd_auth rwk,
owner /var/lib/lightdm/.pulse-cookie rwk,
/var/lib/lightdm/.pulse/ r,
owner /var/lib/lightdm/.pulse/* w,
/var/lib/lightdm/.pulse/* r,
/var/lib/pulse/ rw,
/var/lib/pulse/*-default-sink rw,
/var/lib/pulse/*-default-source rw,
/var/lib/pulse/*.tdb rw,
@{PROC}/[0-9]*/fd/ r,
@{PROC}/[0-9]*/maps r,
@{PROC}/[0-9]*/stat r,


Creating Strong Apparmor Profiles

Recently I read a great blog post from Azimuth Security entitled Poking Holes In Apparmor Profiles. The piece highlights the issues with Apparmor profiles currently deployed and how using Ux, Px, and Cx, can lead to privilege escalation or even a complete breakout from the profile.

It’s because of the points brought up in the post that I tend to audit and recreate profiles for my specific needs. Oftentimes when I read through the profiles I see a lot of #include ‘s that are too ‘wide’ and a lot of profile authors leaving “Ux”‘s in the profile with a note saying they’ll profile it later.

Adding a Ux or Px or Cx is not the worst possible thing, your attacker isn’t suddenly in control of the system. But it gives a huge amount of room to them so you want to avoid it whenever possible. An attacker can write their payload to the disk with the initial exploited program and then use Ux to have the other program run it unconfined.

The story is mostly the same with Px and Cx but instead of full execution you just get potential privilege escalation (going from a very confined profile to a less confined one).

Apparmor can be fixed though. You can read more about that in Azimuth’s blog post because I’m too lazy to talk about it myself/ I just got back from my trip.

Let’s also keep in mind that there are other benefits to Apparmor. Initial exploits often won’t work on a program running in Apparmor because the exploit will try to read/write to some files that might allow for an information leak or give details that the attacker needs to successfully exploit the program. If you aren’t using Ux none of this even matters and, personally, I’ve made it kind of a habit to profile what I can.

AppArmor And Java

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
#include <tunables/global>

/usr/lib/jvm/java-7-oracle/jre/bin/java {
#include <abstractions/base>

network inet stream,
network inet6 stream,
/anon_hugepage//deleted r,
/dev/snd/* rw,
/etc/.java/ rw,
/etc/.java/deployment/ rw,
/etc/fonts/** r,
/etc/host.conf r,
/etc/hosts r,
/etc/java-*/ r,
/etc/java-*/** r,
/etc/lsb-release r,
/etc/nsswitch.conf r,
/etc/passwd mr,
/etc/pulse/client.conf r,
/etc/ssl/certs/java/* r,
/etc/timezone r,
owner /home/** w,
/home/** mrk,
/home/*/.cache/dconf/user rw,
/home/*/.java/** rwk,
/home/*/.pulse-cookie rwk,
/proc/*/cmdline r,
/proc/*/coredump_filter rw,
/proc/[0-9]*/fd/ r,
/proc/asound/version r,
/proc/filesystems r,
/run/resolvconf/resolv.conf r,
/run/shm/ r,
/run/shm/* rw,
/sys/devices/system/cpu/ r,
/sys/devices/system/cpu/** r,
/tmp/ r,
owner /tmp/** m,
/tmp/** rw,
/usr/bin/env ix,
/usr/lib/j2*-ibm/jre/bin/java ix,
/usr/lib/jvm/java-&-oracle/jre/bin/java mr,
/usr/lib/jvm/java-*-sun-1.*/jre/bin/java{,_vm} ix,
/usr/lib/jvm/java-*-sun-1.*/jre/lib/*/client/classes.jsa mr,
/usr/lib/x86_64-linux-gnu/pango/*/modules/*.so mr,
/usr/local/share/fonts/ r,
/usr/share/alsa/** r,
/usr/share/fonts/ r,
/usr/share/fonts/** r,
/usr/share/glib-*/schemas/* r,
/usr/share/icons/** r,
/usr/share/themes/** r,
/var/cache/fontconfig/* r,
/var/lib/dbus/machine-id r,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/ r,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/* r,
@{PROC}/[0-9]*/net/if_inet6 r,
@{PROC}/[0-9]*/net/ipv6_route r,
@{PROC}/loadavg r,



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.

Why I Sandbox Chrome With AppArmor

Google Chrome is a browser designed with least privilege in mind. The Chrome multiprocess architecture sandboxes each tab, the renderer,  the GPU, and extensions and has them use IPC to talk to the ‘browser’ process, which runs with higher rights. The idea is that all untrusted code (websites) is dealt with on the lowest possible level (the renderer has virtually no rights) and then the renderer deals with the trusted browser process. It’s very effective and there hasn’t been a single Chrome exploit in the wild.

On Linux the Chrome sandbox makes use of a Chroot, seccomp mode 2 filters, SUID, and a few other techniques. On the outside this seems really secure, the problem is that the documentation is outdated and not nearly as clear as the Windows documentation.

To use Chroot you need root, so for the browser process to Chroot the other processes it needs root. Chrome seems to find a way around this using SUID where it runs as root under a separate name, I don’t really know, again the documentation doesn’t cover this at all.

Basically, it sounds really strong but if I don’t understand something I can’t consider it secure.

That’s why I apparmor Chrome. I know how AppArmor works, I know it’s track record, I know what my profile allows and what it doesn’t allow. And I know that even if Chrome is running at root my apparmor profile will limit it.

I would post my AppArmor profile for Chrome up here but it’s fairly specific to my needs. For those of you looking to sandbox Chrome make sure you use a separate profile for the sandbox, chrome itself, and the native client bootstrap.

The Definitive Guide For Securing Chrome

This is Part 2 in a series where I’ll be detailing various settings for specific programs and operating systems. For Part 1 (Firefox) click here. I won’t get to do the Ubuntu/ Windows guides today as both of those will probably take days on their own – don’t expect them before Monday.


Google Chrome is based on the open source Chromium project. It differs in that it includes Adobe Flash Player, a PDF viewer, an auto-updater, as well as support for closed source codecs. Chrome makes use of a sandbox based on OS-provided MAC. On Linux it uses a SUID, PID, and Chroot sandbox with Mode 2 Seccomp filters and on Windows it uses various levels of Integrity Access Control.

Chrome is the browser that I consider to be most secure and in this guide I’ll be showing how to lock it down further.

I am choosing Chrome and not Chromium due to including Flash and handling updates automatically.

Privacy Settings

Chrome enables certain features that users may feel pose a privacy concern. You can enable and disable these features in the Chrome ->Settings -> Advanced Settings page.


Those are my specific settings but you can enable/ disable as you please. See this link by Mattcuts to understand communications to Google Chrome.

To make Chrome more private click on the Content Settings.

Chrome allows for a fair level of control over what websites can and can not do. You can disable third party cookies from being set entirely and you can blacklist/ whitelist sites from setting cookies at all.


Next you can type about:flags into the URL bar.

Go enable the feature labeled:

Disable sending hyperlink auditing pings.

Enabling this disables hyperlink audit pings, which can be used to track users.


Chrome does not include a master password feature so you’ll have to use LastPass for something similar. I’ve posted a guide to setting up LastPass here.

Adblock Plus

As Chrome does not yet implement a Do Not Track feature if you’d like to use it you need to install Adblock Plus, which will block ads and tracking.

I also suggest you use this filter to block tracking.

UPDATE: Chrome now supports Do Not Track in the Privacy settings.

Security Settings

Credit to m00nbl00d here.

We can set Chrome to block Javascript globally and then allow by top level domain (ie: .com, .org.) This means that we can block Javascript on many sites without it bothering us. By blocking Javascript on domains like .ru and .cn we actually block a fair amount of pages that could otherwise be used against us.


Notice that I’ve done the same thing with plugins. Something I personally like to do is set Click To Play, and not whitelist any sites. This is a wonderful way to prevent attacks. My recommendation is Click To Play and no whitelist.



HTTPS-Everywhere is an extension developed by the EFF (Electronic Frontier Foundation) that aims to force HTTPS on all sites that make it available.

Many sites, like wordpress, offer HTTPS but don’t default to it. HTTPS-Everywhere will block and redirect requests so that you end up using the HTTPS version.

HTTPS means that the traffic between you and the server is encrypted. That means that no one besides you and the server gets to read or manipulate the data.

This prevents MITM attacks that can be used to sniff passwords or even compromise the machine by redirecting your request to an exploit page.


HTTPSwitchBoard is another Chrome extension aimed at providing a more private and secure browser. The extension allows you to limit requests that the browser makes for a wide variety of content – you can allow a website to load its CSS/images and nothing else, or add in scripting, plugins, video tags, etc on a per-request basis.

It’s quite easy to use, maintains a great blacklist that makes whitelisting safe and easy, and is much faster than conventional content blockers.


AppArmor (Linux Only)

Chrome does not have an AppArmor profile by default on any distro that I know of. You’ll have to make one, so have a look at this guide.

Chrome already makes use of a powerful sandbox on Linux but making use of AppArmor is a good idea. There isn’t a ton of up to date documentation on the Linux sandbox so while we can gather that it’s pretty strong we shouldn’t trust it and therefor AppArmor is a very good idea. What we do know is that the Chrome sandbox makes use of Chroot, a call that requires root privilege, so I’m not sure how they’re accomplishing this (I think they use a separate UID for this and then drop from root) but either way I don’t want anything that can Chroot and Chmod having access to more of my system than it needs.

Seccomp (Linux Only)

Chrome now uses Seccomp filters for plugins. Read about seccomp here.

PPAPI Flash Player

UPDATE: Chrome now uses the PPAPI Flash Player by default, which comes in a very powerful sandbox. Make sure you have your Flash using only PPAPI in chrome://plugins.


Chrome doesn’t update anything other than itself and Flash so make sure to keep your Java, Silverlight, or any other plugins up to date as well as the underlying operating system. And make sure to set your plugins to Click To Play.

And Of Course…

If I’ve missed anything let me know. I don’t think I’ve missed anything worth putting it. I’ve purposefully left ScriptNo (now SafeScript) out as I can’t attest to it actually working correctly 100% of the time and it doesn’t have many important features built into NoScript. I think that m00n’s Javascript trick works fine.

The Definitive Guide For Securing Firefox

This is part 1 in a series where I’ll be detailing various settings for specific programs and operating systems. I’ll be writing a guide for Chrome, Firefox, Windows Vista/7/8, and Ubuntu 12.04 (maybe other things I can think of.) The guide will cover everything I can think of and will cover both system compromise, in-program compromise, and privacy concerns. I won’t cover all subjects today, probably just Firefox and Chrome.


Firefox is the free and open source browser developed by Mozilla. It focuses on user-oriented features like a customizable UI and ensuring user satisfaction through an interactive developer community.

By default without any plugins Firefox is fairly secure in that it makes use of modern mitigation techniques and is quick to patch. This guide will go over some Firefox extensions that you can install as well as  settings that you can change to improve security and privacy.

Privacy Settings

First up we’ll change our privacy settings to include the Do Not Track header, which I recently posted about. We’ll also be disabling third party cookies as these are typically only ever used for tracking users (though they can have legitimate uses, like logging into websites via third party logins).

Firefox -> Edit -> Preferences -> Privacy

It should look like this after you’ve changed the settings:


Security Settings

From the privacy tab you can click the next tab – Security.

Here we can set our master password. This password will encrypt all others so that if anyone gains unauthorized access to your system they will no be able to gain access to your information.

See this guide for creating a strong password.

Content Settings

Firefox lets you allow or deny Javascript throughout the browser in the content settings page. Disabling Javascript will break many sites but it will improve security – I recommend NoScript instead.


NoScript is an extension developed by Giorgio Maone. NoScript is a default-deny system that blocks a webpages ability to run scripts or plugins. It also makes use of a strict XSS filter and clickjacking prevention.

By default NoScript blocks the following:


This renders most attempts at exploiting the browser unsuccessful and will protect even whitelisted pages fairly well.

The problem with NoScript is that there is a ton of user interaction required. You have to whitelist every site you want to visit. It’s a pain. But if you’re after high level of security that’s what I recommend. If you globally disallow (default) you’ll benefit even when you whitelist a website.

Even if you hate the interaction I highly recommend you install NoScript and turn on the “Allow Scripts Globally” feature because it will still provide further improved security.

With NoScript ‘Allow Scripts Globally’ you miss out on the full extent of its protection but even then you’ll benefit from a few really great protections such as:

The XSS Filter – NoScript’s XSS is kinda the XSS Filter to compare all other XSS Filters to.

ClearClick – Clickjacking is a method used by attackers to trick a user into clicking a hidden or invisible ‘button’ that can lead to an exploit page or even a bank transaction. ClearClick is the only protection for this currently implemented.

CSRF Protection – CSRF is harder to explain. It attacks from the users end of the system so it can do things like get into your email account and bypass protections because it all originates from ‘you.’

MITM Protection – Man In The Middle attacks happen when, simply, the attacker is between you and the server. SSL is the typical solution but you can spoof certs and hijack even SSL communications or just attack mixed content transmissions. NoScript implements multiple protections here.

So, there you have it. Even with Scripts Globally Allowed NoScript is going to make your Firefox much more secure.


HTTPS-Everywhere is an extension developed by the EFF (Electronic Frontier Foundation) that aims to force HTTPS on all sites that make it available.

Many sites, like wordpress, offer HTTPS but don’t default to it. HTTPS-Everywhere will block and redirect requests so that you end up using the HTTPS version.

HTTPS means that the traffic between you and the server is encrypted. That means that no one besides you and the server gets to read or manipulate the data.

This prevents MITM attacks that can be used to sniff passwords or even compromise the machine by redirecting your request to an exploit page.


Convergence is an extension that aims to solve many of the issues we see today with SSL and MITM attacks.

Check out this explanation on it here.

It hasn’t been updated in ages, and I’m not even sure if it’s supported anymore, so take this tip with a grain of salt – results may vary.

AppArmor (Linux Only)

I’ve written a guide for AppArmor already but I’d like to highlight that Ubuntu comes with a Firefox profile by default. It probably needs a bit of tweaking but if you follow the guide it’s easy to set up.

To set your apparmor profile to enforce simply enter:

# aa-enforce /etc/apparmor.d/usr.bin.firefox

Afterwords your Firefox will be held in a tight sandbox, which will prevent and contain exploits.


Adobe Reader is one of the most commonly exploited applications and although it has improved you may want to check out PDF.JS.

You can use this simple extension to install it and Firefox will handle PDF through Javascript.

You can read more about PDF.js here.

PDF.js is arguably less secure than Adobe Reader as Reader will run within a sandbox. The goal of PDF.js is to reduce attack surface by having PDFs rendered by the Javascript engine already present in Firefox.


Always make sure to keep Firefox and all of its plugins up to date. This is critical on Windows where out of date plugins consistently lead to compromise.

And Please…

Firefox is not my default browser and hasn’t been for over a year now. If you know of any other methods for securing it please leave me a comment and I’ll try to fit it in. Thanks.