Grsecurity On Desktop Is Simple

Some people find the idea of compiling their own kernel to be fairly daunting. And, to an extent, it is. There’s greater chance for issues to arise when you start handling things yourself if you aren’t careful. But the benefits are very significant.

I’ve been running a Grsecurity patched kernel for months with very few issues – most have been due to me messing around and ATI drivers having massive security flaws. Performance is not any worse that I can tell – I feel absolutely no ‘bog down’ in any way.

Running your kernel patched with Grsecurity is the number one best way to stay secure. Every single thing I’ve written about is made better when you run it with a secure kernel, and Grsecurity is the leader by a long shot when it comes to kernel security.

Actual compile time on my laptop takes about 2 hours. That’s actually not that bad – consider that it runs in the background, the system is fine and responsive while it’s going on, and it’ll easily be done by the time I wake up.

All of the troubleshooting will happen at the beginning, the first compile. After that it’s smooth sailing.

You get a kernel that’s considerably more secure and faster if you take the time to optimize it.

Here’s a guide to patch your Grsecurity kernel.

Explaining Chrome’s Linux Sandbox

Note: The documentation for Chrome’s Linux sandbox is lacking. This is my attempt to make sense of it and clarify how it works for users who may not want to sift through multiple docs on the subject. If I have misinterpreted, let me know, some of the docs are out of date and I may not have been informed.

Chrome is well known for its sandbox, which has held up incredibly well over the years – not a single in the wild attack against it. But on the Linux side of things it’s even more impressive, Chrome’s sandbox is immensely more powerful than on Windows. Though the architecture is similar, the mechanism is fairly different.

Chrome’s architecture is made up of multiple parts – on Linux there is a broker, your SetUID Sandbox process, and your tabs, renderer, plugins, and extensions (the Zygote processes).

The Chrome-Sandbox SUID Helper Binary launches when Chrome does, and sets up the sandbox environment. The sandbox environment is meant to be restrictive to the file system and other processes, attempting to isolate various Chrome parts (such as the renderer) from the system.

A sandboxed process is put inside a Chroot, a sort of a virtual file system (chroot = change root, it’s a new root). It basically gets its own file system to work with, an din this case, it’s not given any write access to the system. The limitations imposed on the process prevent it from escaping the chroot.

The sandboxed process is also provided a PID namespace (a way for a process to look like it’s standalone on the machine,  or among a subset of processes), denying it the ability to use ptrace() or kill() other processes. ptrace() in particular is dangerous as it allows processes to read or manipulate data in other processes. Sandboxed processes are unable to ptrace() each other as well (set to undumpable).

A network namespace is used as well in order to prevent sandboxed processes from connecting out – not much documentation on this.

The Broker process, which remains unrestricted by SUID, is what handles decisions about downloading files, writing to the disk, etc. It handles the dangerous stuff, and is unrestricted, but it is separated from the areas of the program that are most open to attack. Using an Apparmor profile will allow restriction even of the broker process. Otherwise it remains confined purely by DAC.

The next layer of restriction is provided by the Seccomp-BPF sandbox. Seccomp filters are something I’ve written about before. Their goal isn’t to protect the system from damage, like the SUID sandbox does, but to protect the system from further exploitation.

Seccomp-BPF works by restricting the system calls that programs can make. The implications of this are covered in this post. A quick summary is that a sandbox, or any form of access control, is only as powerful as the kernel. It is very often the case that, rather than trying to find issues with the sandbox itself, an attacker can simply go after the big buggy kernel running underneath it. An attack on the kernel allows for a full bypass of the sandbox.*

Seccomp works by restricting access to the kernel by filtering the ‘calls’ that can be made to it. The fewer calls a program can make the fewer ways it can exploit the system. Suddenly the kernel isn’t this massive glob of attack surface, it’s a much smaller are, with monitored interaction between it and the program.

Chrome on Windows had its sandbox broken at Pwn2Own by MWRLabs. It was, in fact, a local kernel vulnerable that allowed them to bypass the sandbox once they’d gained access to the renderer. Such an attack would be far more difficult on a Linux system with Seccomp enabled.

Overall the sandbox works by reducing the potential for damage and reducing the potential for local exploitation. Chrome is, as always, pouring work into their security. Their sandbox is very impressive, and I would love to see some research into breaking it.

There was a ‘partial reward’ for PinkiePie exploiting ChromeOS, but it was unreliable. No details have been released yet, quite unfortunately.

*Plug for Grsecurity here. See my guide for setting up a hardened Grsec kernel. Seccomp limits kernel attack surface, Grsecurity makes the entire kernel more difficult to exploit.

Against User Education – In Depth

This post is meant to be a comprehensive overview of the costs and benefits of user education in an enterprise environment (though the same applies everywhere). I have talked time and time again about users not being educated, and why that’s the case. A very significant portion of my posts have been about this subject, and it seems that this subject has gotten a lot more popular in the last few weeks, so I’m going to make a post with definitive evidence.



The costs of a security technique are always to be considered. Sometimes the cost is performance overhead, downtime, annoying popups, money, whatever. Sometimes the costs are worth it, sometimes they aren’t, but they’re always going to be there.

So what are the costs of user education?

1) Time: Your IT staff is going to have to take time to meet with users, or at the very least write something up for them. As a single session is unlikely to be effective (more on this later) it’s more useful to have multiple sessions, and thus a significant amount of time is spent on user education.

2) Money: Your IT staff is getting paid either way. But what about the employees? They’ve got work to do – billable hours. An hour of IT is an hour you’re paying them to learn, and another hour taken away from their work. Is that a significant cost? Maybe, maybe not.

These are really the two costs for user training, as it’s not a software technique, and really just involves taking time to talk to someone. The issue is that it’ snot just the IT staff, which is paid for security, but it’s your everyday employee.



Simple Polices On Deaf Ears

The real meat here is the potential and perceived benefits of this training. This is less clear cut – it’s not a list of things users will or won’t do, but instead I’ll look at how likely your training was to be effective.

Let’s look at one of the simplest policies, probably a policy every company will try to enforce, and something we constantly try to teach users: use a strong password.

Do you know what we’ve learned from password dumps? It’s 2012 and these are still the most common passwords:



Yes, the top password from the Yahoo password dump is 123456, and the next one is “password”, followed by “welcome”. The advice to “use a strong password” is probably the most pervasive and consistent advice in the security community. Honestly, I think it’s the number one thing people will tell you to do, and that goes triple for a corporate environment, where passwords are critical.

And yet passwords have not improved. And I’m quite positive that if you look at a corporate environment you will find very similar results, but with the corporate policies ‘smushed’ on: password12!! instead of password, because someone decided to force them to use a number and symbol.

Users Don’t Care, And It’s Not Irrational

A Microsoft research paper explores why exactly users are incapable of following policies. Why is it that time and time again they don’t follow company advice, or so-called ‘common sense’? The answer is really very simple, and would surprise most people: they’re actually making entirely rational decisions.

Everyone performs rudimentary cost benefit analysis every day, for any task that requires a choice that will lead to a consequence. Should you have some ice cream? Go for a run? Study? Play video games? In our head we make simple assumptions like “well I can study, but it won’t be very fun, but it’ll pay off later” and come to a conclusion.

Users in a corporate environment are no different, you tell them to come up with a strong password and they ask themselves “I can use a strong password and something won’t happen, but I’ll absolutely have a hard time remembering it and it’ll be a pain to type”.

The key point here is that there are definitive and predictable costs and only theoretical consequences. A user is going to be annoyed having to retype their password 5 times. A strong password might prevent an attack.

So you have to convince your users that an attack is imminent and likely, and that the pressure is on them… to which I would imagine they’d ask why it’s their job and not yours.

It Wouldn’t Matter If They Cared

Even if your users could manage to care at all about the security of their systems more than how annoying long passwords are it very likely wouldn’t matter. That’s for two reasons:

1) You can’t get them all to care. If one user is exploited an attacker is on the network. Is the game lost? No. But if you expect user education to save you after this point, good luck.

2) They don’t know anything about computer security. Even if they did care about it, they’re incompetent in the subject. We already know they have zero clue about creating strong passwords, even when policies are enforced, so what makes you think that they’ll be able to do anything else better? They are very unlikely to know how to keep every single program up to date, how to generate strong passwords, how to verify a site is using TLS, how to differentiate between a malicious email and a legitimate one. Humans just aren’t good at that stuff, and you’re not going ot be able to teach it in a reasonable amount of time (again, assuming they care enough to learn, which they don’t).


So I’ve been meaning to write this for a while, and I write about this stuff a ton anyways, but then Schneier put somethign out and it got all this attention and I thought “Oh, look, people actually care.”

So there’s my two cents on the matter. You can see that passwords haven’t changed, you can understand why nothing has changed, and you can consider the potentially very significant costs of implementing user training, and ask yourself if you can’t find a better use for that time/ money.



Windows Hardening Guide

Collaborative post by @0xdabbad00 ( and @insanitybit (



This guide is focused on Windows Vista, 7 and 8 systems for personal use.  This guide is not concerned with the following:

– Not Windows XP or earlier because they simply do not have the security features necessary to securely use.  A lack of ASLR and SEHOP, no integrity levels, a kernel with exposed attack surface, and a general lack of privilege separation makes securing XP a task best left to science fiction.

– Not enterprise environments, though some of this information can certainly translate over

– No IDS, DNS log monitoring, or other network related activities that are usually only reasonable to spend time on in enterprise environments.


Disrupt, deny, and degrade attacks through reduction of attack surface area and implementation of modern mitigation techniques.  Finally, prepare for the worst, assume APT.

Reduce Attack Surface

Vulnerabilities require one thing – code; if the code exists, so will vulnerabilities. The best way to avoid being exploited is to ensure there as few vulnerabilities as possible for the attacker to exploit.  The simplest and most effective way to do that is to minimize the amount of software on the system – less running code means less places for your attacker to poke at.

There are some key areas that are commonly attacked:

1) PDF Reader:  If possible uninstall Adobe Reader and use Chrome or Firefox’s built in PDF reader.  If you must use Adobe Reader ensure that Javascript is disabled and that Protected Mode is enabled in the security settings. There will be other steps in the guide for hardening your PDF reader further.

2) Java: Java is one of the most highly exploited programs on Windows systems. It’s a very easy target for attackers, and this is unlikely to change for a long time. If you can’t remove Java altogether I highly suggest changing your browser settings to “Click To Play Plugins”.

3) Windows Services: Windows, like any other mainstream OS, comes with a ‘default compatible’ attitude – it has to work for everyone. That means it comes with a large number of services running by default. These services are exploitable, and have been used for local privilege escalation in the past. Disable any Windows services that you don’t need. Deciding which services you do or don’t need requires a bit of research, as different users require different things.

For other software you’ve installed, such as an instant messaging client or torrenting client, always ensure that you have the latest version and keep track of security releases.  Many software applications have their own auto-update mechanisms, make sure you enable it if you don’t think you’ll stay on top of patching yourself.  You can also use software like Secunia’s PSI which will scan the software you have installed to ensure it is up-to-date.  Secunia PSI can be useful to install once and check for out-of-date software, but it’s somewhat awkward to use and have running regularly, so I uninstall it after running it once. Alternatively you can use the FileHippo updater, which is portable and will check for any out of date software in its repository.


Disrupt Exploits

Given the possibility that your software may be vulnerable to 0-day threats or known threats that have not yet been patched, the next line of defense is to use techniques that disrupt exploits from being successful.  This is what EMET does.  It takes a bit of configuration, so use insanitybit’s write-up as a guide:


If an exploit does manage to get execution, the next line of defense is to break it’s ability to work correctly by denying it access to different APIs.  The best solution for this is AmbushIPS by @scriptjunkie1  This will protect best against ROP based exploits (which usually disable DEP as one of their steps which AmbushIPS check for), but also against exploits which have obtained full arbitrary execution.  If the attacker knows your are using AmbushIPS, he could likely modify his exploit to work around it, so to some degree this is security through obscurity, but setting up an IDS/IPS can prove very beneficial to those willing to manage them.  You can also write your own signatures for AmbushIPS to check for, which adds further unknowns for attacks.


AmbushIPS cannot only block exploits, but it can also log chosen Windows API calls to a remote server.  This could be helpful in identifying when an attack occurred and how, post-mortem.


Block Payloads

Although the stage in which an attacker launches their payload is both optional and late in the game, those looking to improve their security may look into AppLocker, an Anti-Executable security solution available for the more enterprise oriented Windows editions (Windows Server 2008 R2, Windows 7 Ultimate and Enterprise, Windows Server 2012, and Windows 8 Enterprise). Anti-Executable software works by preventing processes from launching based on a whitelist and blacklist. If Firefox.exe is running, and it tries to run evil.exe, and evil.exe is not whitelisted, then it will not run. This is most helpful for preventing malware that uses legacy techniques, and making it more difficult for an attacker to gain persistence.

AppLocker rules come in three types: path, hash, and my favorite, publisher.

A path rule is really quite weak. It basically says that ‘only files from this path can execute’, which means that all an attacker has to do to bypass that rule is write to the path and execute.

Hash rules are much more difficult to get around, but they’re also horribly difficult to maintain. Every time your program updates you need a new hash.

Publisher rules are based on certificate information. This is much easier to deal with, as it’ll only allow specific programs to run, but it won’t have to be updated for every program update.

While AppLocker is not enough for any attack that accounts for it, it can be useful when layered on top of other techniques. Just be sure that you realize its shortcomings.


Prepare For The Worst

Given the possibility that your laptop could just simply be stolen, encrypt your data with TrueCrypt (free) or Windows BitLocker (if you have Windows Enterprise or Ultimate editions).  Any and all sensitive information (ex. proprietary code for your company if you are a software developer) should generally be stored in some type of encrypted container.  Be aware that if you try to only encrypt specific data, Windows will still save a hibernation file (a copy of the RAM) to the system partition which may contain your sensitive information.

Here are guides for TrueCrypt and BitLocker.


Security advice not specific to Windows

Your browser is your main attack surface on a personal system, so take efforts to secure that by using various extensions (NoScript and HTTPS-Everywhere). You can find guides for securing Firefox and Chrome here and here. As a user if you secure your browser you’re securing the area that most attackers will attempt to exploit.

Many websites now offer dual-factor authentication, such as GMail and Facebook.  Take advantage of these, so you don’t end up getting locked out of your own email and social network sites if you ever get owned.

Do your banking from a different computer that you use infrequently, but still keep up-to-date on patches!  Have your various website accounts send password resets to an email account that you only access from this banking computer. Make sure you’re connecting to these websites through a secure and trusted network.



There is a lot of security software for Windows out there: Some legitimately adds protection, and some unfortunately exposes you to more attacks than it protects you from.  It’s impossible to cover it all in a single post, so we tried to stick to the built-in and free tools that are most important.

If you follow this guide you’ll be making an attackers job much more difficult. Though there is no silver bullet, and Windows security software is somewhat limited, you can use this guide to significantly improve your chances when facing the latest 0-day exploit in your browser.

As always, if you have suggestions for the guide, corrections, or general comments, please feel free to leave that all in the comments section and we’ll have a look.


Sandboxing Popularity Will Do Two Things

Sandboxes are getting more popular, with Chrome, Internet Explorer, Adobe Reader and FlashPlayer all implementing some version of a sandbox. So far these sandboxes have been very effective – attacks against these programs either don’t exist or they’ve shrunken down to fairly rare events. While attackers have momentarily shifted their focus to unsandboxed programs, such as older versions of these programs, or other plugins like Java, there will likely come a point where they’re faced with actually dealing with them. So how will they fair?

There are two ways hackers will monetize a situation in which a sandbox is involved. Given the scenario where the vast majority of users are now only running sandboxed processes (no more silverlight or Java) an attacker will be forced to either:

1) Break out of the sandbox


2) Monetize from within the sandbox

Breaking Sandboxes

In my last post I briefly wrote about Chrome getting hacked at Pwn2Own. The bypass of Chrome’s notoriously strong sandbox took place on Windows, and it made use of a kernel vulnerability to get privilege escalation.

While breaking Chrome’s sandbox through design issues is very difficult, and the code for the broker process is relatively small, the Windows Kernel is large and complicated, ripe for exploitation.

The kernel isn’t the only vulnerable piece of software viable for sandbox escalation. Security software is constantly poking holes in sandboxes – you can get a full bypass of Chrome’s sandbox just by attacking the AV that injects into it.

Hackers are very likely to make use of local privilege escalation attacks, especially for high value targets, in order to monetize systems that use sandboxes.

In-Sandbox Attacks

Attackers do one thing really well, and it’s pretty much universal – they make money. It doesn’t matter if they’re just getting your emails, some paypal info, or whatever else they can get their hands on, they will usually be able to find a way to sell or use that information to their advantage.

Just because an attacker is stuck in a sandbox does not mean they can’t make money. Depending on sandbox architecture they can potentially have more than enough information, just by compromising your browser, to steal bank info, credit card credentials, email passwords, and more.


There is one thing we can be sure of – attackers won’t just give up. Maybe they’ll accept losses, maybe they’ll change their focus, but hackers aren’t going anywhere. There is still far too much money to be made.

Whether they break the sandboxes or learn to work within them attacks are still going to happen.

Chrome Gets Hacked – Pwn2Own 2013

So Pwnium 2013, held at Cansec West, started today. And while details of the attacks aren’t out, one in particular stuck out to me. This post can be considered something of a “Part 2” to my “Securing Insecure Systems” because it highlights the absolute number one most important thing – a secure kernel is necessary for a secure system.

MWRLabs was the only contested booked for Chrome hacking, and they were successful, leveraging initial RCE/ASLR bypasses on Windows 7 to gain access to Chrome. From there they exploited a kernel vulnerability, and that’s where the fun is.

We also used a kernel vulnerability in the underlying operating system in order to gain elevated privileges and to execute arbitrary commands outside of the sandbox with system privileges.

What people need to realize is that no matter how tight Chrome’s sandbox (Untrusted has no read/write access to the  entire file system, and that’s where they started) there’s an entire complex full-of-vulns kernel sitting right there, ripe for exploitation. And MWRLabs took advantage of that – they broke through the sandbox.

And what does that prove? It proves that no matter what the hell you do to restrict things like file access, if you leave your kernel exposed, you are vulnerable.

On Linux I see, time and time again, that people feel they don’t need PaX/Grsecurity. These people state “Oh, well we have SELinux”. This proves that MAC is not enough. You’re trying to solve an insecure kernel by putting a piece of code in your kernel that restricts file access… nope.

Thankfully, on Linux, there are ways to limit kernel attack surface. You’ve got seccomp mode 2 filters, which filter access to the kernel. By limiting kernel attack surface you make the kernel more difficult to exploit – though this does not negate the need for a patched and hardened kernel.

So what do you want to take from this?

1) No. You aren’t secure if you don’t patch.

2) No. You aren’t secure just because you use SELinux.

The AntiVirus Era

For the last 30 years the computer security industry has been dominated by antivirus. Companies like Symantec are worth billions of dollars, and their products are deployed across millions of enterprise machines. For the average home user products like your typical antivirus may be enough, though I wouldn’t count on it alone. When it comes to an enterprise environment AV technology is critically flawed, and incapable of handling the threats presented to it.

An antivirus is based on the idea that if you can analyze malware from the past you can detect malware in the future. It’s a simple idea, and it can be effective for massive campaigns that are meant to be spread out across as many users as possible, because attackers only have time to create one payload, and then ‘crypt’ it, and try to avoid detection through automated means.

Basing security on research having to do with ‘in the wild’ malware is something I’ve talked briefly about on Twitter. I’d like to expand on that. When you build a security product around the threat landscape, and when you focus your research on the current threat landscape, it will probably be outdated by the time you publish it. For one thing, malware campaigns change drastically from country to country – trying to average it out or boil it all down is going to be way too broad to be useful. On top of that, malware is constantly changing. We see new threats, drastically new threats even, every year. In the last few years some of the most advanced atypical malware has been discovered, and there are many people who believe this will continue. So for research to talk about ‘the now’ in a field that is so fast paced, to me, is a waste of time.

In the case of what has been dubbed ‘Advanced Persistent Threats’ (APT), an oft overused term, the threats are targeted to the intended victims. Instead of attacking the world you go after a company. The effort involved in a targeted attack is greater, and it may take more time, but the payout can be estimated as ’10x’ what a mass campaign would be. Beyond pure monetary gain there’s also other motivators, such as belief in a cause – hacking as a form of activism is referred to as ‘hacktivism‘, and it has become far more prominent over the last few years.

If we take what we know about an AV, that it must rely on detection, and that the detection it uses relies on analyzing past malware, it isn’t difficult to see how a highly targeted attack would bypass it. Simply by virtue of being targeted, and new, an attacker will have a massive advantage against any antivirus. This has been shown many times, but most recently we can see this demonstrated through the New York Times. As some of you may know the New York Times was recently hacked, and they reported on the findings surrounding the incident. One highlight from the piece:

Over the course of three months, attackers installed 45 pieces of custom malware. The Times — which uses antivirus products made by Symantec — found only one instance in which Symantec identified an attacker’s software as malicious and quarantined it, according to Mandiant.

To put it bluntly, Symantec failed somewhat miserably. But you can’t really blame a product like theirs for being ill equipped at dealing with something so outside of what it’s meant to deal with. And I don’t think any other antivirus would have done all that much better – they’re simply not able to deal with these situations.

This is one in quite a few cases. Zero-Day exploits are being sold to governments, and those governments are in turn hacking each others citizens. There has been evidence in the past that exploits shown by Vupen, and purchased by their customers, have been used in the wild. Stuxnet, Duqu, Flame,  all advanced pieces of malware delivered through advanced exploits, and they infected numerous users. And it took a very long time for antivirus vendors to catch on to them and create definitions for them.

So this really begs the question – is this ‘era of antivirus’ finally over? The antivirus industry has been dominated by a very specific type of program, is that really going to change?

The answer is complicated, it’s one of those annoying ‘yes and no’ situations. Obviously antivirus is a terrible addition to your security, and in my own opinion it’s far more of a burden than a benefit, but that doesn’t mean it’s going anywhere. There are no decent replacements. If we dump the antivirus we’re left with, god forbid, Firewalls – another massive waste of money that companies like to pour resources into.

Some replacements have cropped up. Nothing impressive… at all. Various products take different approaches, a few even implement sandboxes, but they’re pretty pathetic and feel very ‘thrown together’. Comodo Internet Security is a very ‘different’ product – it’s a HIPS and AV built around their Firewall. While it can in theory be used to prevent against APT there is absolutely no way it will in practice, anyone who has tried using it will be able to attest to that. And most other products suffer from the same issues, OK in theory, horrible in practice.

Beyond all of that, companies aren’t run by security experts. Hell, even IT teams aren’t run by security experts. I happen to go to a school that has a focus on computer security, and even it focuses on the wrong topics (though it’s far better than most). Reflecting this is the culture surrounding security incidents. You generally have two responses:

1) Blame some user somewhere for clicking something

2) Invest in more expensive Firewalls and other useless security software that has failed time and time again (I don’t hate Firewalls, I hate Firewall businesses)

So I wouldn’t expect the response to actually be, you know, productive in some way. So even if there were products to fill the gap that AV would leave it would make no difference, IT is broken.

I hope to personally kill the AV one day, and I’ll be happy when it’s dead. Detection isn’t a bad thing, testing against current threats isn’t a bad thing, but god damn do not make it the core of your product. I’ve seen so many pathetically insecure products touting how great they are just because, oh my god, they can block some generic malware – not too impressive.

Security is, as always, about principals. Some things are universal – entropy, uncertainty, least privilege. You know what makes APT hard? When an attacker doesn’t know what they’re up against, when a remote attack might fail. There is nothing scarier to a hacker than a potentially failed attack – if a system gets accidentally DOS’d, as opposed to hacked, the IT team is going to be on alert. Security research should focus on further implementation of these principals, not on how to stop yesterdays malware using techniques from the late 80’s.

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.

Security Software Usage Of Mitigation Techniques With Slopfinder

I recently read a post that used static analysis of executable files to see which applications were using DEP/ASLR and to what extent. This inspired me to perform the same analysis with the same tool, but on security software.

Antivirus software runs with very high privileges on a system, and it deals directly with malicious, attacker controlled code. Ensuring that modern mitigation techniques are enabled is essential when designing security software, as your code is inherently exposed to an attacker. In other words, the code here should be held to the highest standard. A

nalysis performed in a Windows 8 64bit VM using slopfinder in Chrome Stable. Slopfinder is a tool that performs static analysis on executable files to check their security flags, whether or not they make use of DEP / ASLR.

Using Slopfinder is as simple as dragging/ dropping a folder full of executables and then looking through the results, which is what I’ve done here.

Default installations – trial software used if available for Pro versions. Some of these programs install “web guards” that are actually glorified Ask Toolbars or some other BS toolbar- these are included in results, they’re part of the ‘security’ package and they’re entirely relevant.

If I don’t specify DEP/ASLR it means both are disabled. This is the case for the majority, which I’m assuming has to do with ‘permanent’ DEP, as I’d be very surprised if DEP were really disabled so frequently – but who knows! UPDATE: Here is an explanation for the DEP.

Keep in mind that just because some files don’t support ASLR or DEP doesn’t mean you’re vulnerable. Some of these files won’t ever interact with ‘attacker code’ – there’s little reason for program uninstallers to support ASLR, for example, and the same goes for installers.

If anyone has more information to add (for example if one of these offending DLLs is particularly critical, like if it’s loaded into the browser) I’ll happily add it in.

Microsoft Security Essentials/ Windows Defender

I found no executable files not compiled with DEP/ASLR.

Avast! Pro Trial (25)
















/Avast/Setup/INF/aswTdi.sys /





















Avira Premium Trial + Toolbar (41)







/AntiVir Desktop/aecore.dll

/AntiVir Desktop/aeemu.dll

/AntiVir Desktop/aeexp.dll

/AntiVir Desktop/aegen.dll

/AntiVir Desktop/aehelp.dll

/AntiVir Desktop/aeheur.dll

/AntiVir Desktop/aeoffice.dll

/AntiVir Desktop/aepack.dll

/AntiVir Desktop/aerdl.dll

/AntiVir Desktop/aesbx.dll

/AntiVir Desktop/aescn.dll

/AntiVir Desktop/aescript.dll

/AntiVir Desktop/aevdf.dll

/AntiVir Desktop/avacl.dll

/AntiVir Desktop/avevtrc.dll

/AntiVir Desktop/aebb.dll

/AntiVir Desktop/libapr-1.dll

/AntiVir Desktop/libapriconv-1.dll

/AntiVir Desktop/libaprutil-1.dll

/AntiVir Desktop/libdb44.dll

/AntiVir Desktop/rchelp.dll

/AntiVir Desktop/unacev2.dll

/AntiVir Desktop/FAILSAFE/aebb.dll

/AntiVir Desktop/FAILSAFE/aeemu.dll

/AntiVir Desktop/FAILSAFE/aeexp.dll

/AntiVir Desktop/FAILSAFE/aegen.dll

/AntiVir Desktop/FAILSAFE/aehelp.dll

/AntiVir Desktop/FAILSAFE/aeheur.dll

/AntiVir Desktop/FAILSAFE/aeoffice.dll

/AntiVir Desktop/FAILSAFE/aepack.dll

/AntiVir Desktop/FAILSAFE/aerdl.dll

/AntiVir Desktop/FAILSAFE/aesbx.dll

/AntiVir Desktop/FAILSAFE/aescn.dl

/AntiVir Desktop/FAILSAFE/aescript.dll

/AntiVir Desktop/FAILSAFE/aevdf.dll

/AntiVir Desktop/FAILSAFE/aecore.dll

AVG Internet Security Pro (27)

/AVG Secure Search/

/AVG Secure Search_toolbar.dll (Browser componnent it would seem)

/AVG2013/HtmLayout.dll (Also possible browser component)

























McAfee All Access – Total Protection (14)

Note: McAfee became increasingly unstable on my system. I uninstalled it before I could analyze the Chrome extension that it installs.



/McAfee Online Backup/MOBKbackup.exe

/McAfee Online Backup/MOBKconf.exe

/McAfee Online Backup/MOBKshell.dll

/McAfee Online Backup/MOBKstat.exe

/McAfee Online Backup/backup.dll

/McAfee Online Backup/oem.dll

/McAfee Online Backup/MOBK.sys

/McAfee Online Backup/librs2.dll





Norton (17)

/Norton 360/Engine/

/Norton 360/Engine64/

/Norton 360/Engine64/

/Norton 360/Engine64/

/Norton 360/Engine/

/Norton 360/Engine64/

/Norton 360/MUI/

/Norton 360/Branding/ NO ASLR

/Norton 360/Engine/

/Norton 360/Engine/

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/2013.1.0.32_0/npcoplgn.dll NO ASLR (browser plugin)

Sophos Antivirus (No Firewall) (F-)

It doesn’t seem that any of the executable files support ASLR. Many do not support DEP as well, including quite a few that seem to interact with the web. When your “xmlparser.dll” doesn’t show DEP/ASLR support… yikes. There’s no point listing them all. Sophos gets an F- here.

Panda Cloud AV Pro (42)

/pandasecuritytb/pandasecurityDx.dll (Possibly part of the browser extension)

/pandasecuritytb/pandasecuritytb.dll (Possibly part of the browser extension)

/Toolbar Cleaner/ToolbarCleaner.exe


/Toolbar Cleaner/uninstall.exe

/Panda Security/Panda Cloud Antivirus/cc3290mt.dll

/Panda Security/Panda Cloud Antivirus/bcbie120.bpl

/Panda Security/Panda Cloud Antivirus/MiniCrypto.dll

/Panda Security/Panda Cloud Antivirus/PAV2WSC.exe

/Panda Security/Panda Cloud Antivirus/Pavsddl.dll

/Panda Security/Panda Cloud Antivirus/PSBoot.dll

/Panda Security/Panda Cloud Antivirus/PSBoot.sys

/Panda Security/Panda Cloud Antivirus/pskmad.sys

/Panda Security/Panda Cloud Antivirus/PSUAAlerts.dll

/Panda Security/Panda Cloud Antivirus/PSUNConsole.dll

/Panda Security/Panda Cloud Antivirus/PSUNCtrl.bpl

/Panda Security/Panda Cloud Antivirus/PSUNFwConfig.dll

/Panda Security/Panda Cloud Antivirus/PSUNMsg.dll

/Panda Security/Panda Cloud Antivirus/PSUNPnlConfig.dll

/Panda Security/Panda Cloud Antivirus/PSUNProcMon.dll

/Panda Security/Panda Cloud Antivirus/PSUNReports.dll

/Panda Security/Panda Cloud Antivirus/PSUNScan.dll

/Panda Security/Panda Cloud Antivirus/PSUNSuspects.dll

/Panda Security/Panda Cloud Antivirus/putczip.dll

/Panda Security/Panda Cloud Antivirus/putsig.dll

/Panda Security/Panda Cloud Antivirus/puturar.dll

/Panda Security/Panda Cloud Antivirus/putuzip.dll

/Panda Security/Panda Cloud Antivirus/borlndmm.dll

/Panda Security/Panda Cloud Antivirus/RKPavProc64.sys

/Panda Security/Panda Cloud Antivirus/rtl120.bpl

/Panda Security/Panda Cloud Antivirus/SetupUI.dll

/Panda Security/Panda Cloud Antivirus/bspatch.exe

/Panda Security/Panda Cloud Antivirus/USBVacineDLL.dll

/Panda Security/Panda Cloud Antivirus/vcl120.bpl

/Panda Security/Panda Cloud Antivirus/vclactnband120.bpl

/Panda Security/Panda Cloud Antivirus/vclie120.bpl

/Panda Security/Panda Cloud Antivirus/vclx120.bpl

/Panda Security/Panda Cloud Antivirus/WinSkinc2009.bpl

/Panda Security/Panda Cloud Antivirus/xmlrtl120.bpl

/Panda Security/Panda Cloud Antivirus/DG/MsiZap.Exe

/Panda Security/Panda Cloud Antivirus/DG/PAV2WSC.exe

/Panda Security/Panda Cloud Antivirus/Tools/PandaSecurityTb.exe

Panda left its god damn blekko crapware in my browser.

Comodo CIS (71)

.cav files are definition files, they shouldn’t matter. I realized this partway through and stopped logging them.



/COMODO/COMODO GeekBuddy/uninstall.exe

/COMODO/COMODO Internet Security/cmdagent.exe

/COMODO/COMODO Internet Security/cmdcomps.dll

/COMODO/COMODO Internet Security/cmdhtml.dll

/COMODO/COMODO Internet Security/cmdinstall.exe

/COMODO/COMODO Internet Security/crashrep.exe

/COMODO/COMODO Internet Security/framework.dll

/COMODO/COMODO Internet Security/cfpupdat.exe

/COMODO/COMODO Internet Security/inspect.sys

/COMODO/COMODO Internet Security/msica.dll

/COMODO/COMODO Internet Security/platform.dll

/COMODO/COMODO Internet Security/cfpconfg.exe

/COMODO/COMODO Internet Security/cfp.exe

/COMODO/COMODO Internet Security/cavshell.dll

/COMODO/COMODO Internet Security/signmgr.dll

/COMODO/COMODO Internet Security/cavscan.exe

/COMODO/COMODO Internet Security/7za.dll

/COMODO/COMODO Internet Security/scanners/pe32.cav

/COMODO/COMODO Internet Security/scanners/dosmz.cav

/COMODO/COMODO Internet Security/scanners/dunpack.cav

/COMODO/COMODO Internet Security/scanners/extra.cav

/COMODO/COMODO Internet Security/scanners/gunpack.cav

/COMODO/COMODO Internet Security/scanners/heur.cav

/COMODO/COMODO Internet Security/scanners/mach32.dll /

COMODO/COMODO Internet Security/scanners/mem.cav

/COMODO/COMODO Internet Security/scanners/pe.cav

/COMODO/COMODO Internet Security/scanners/common.cav /

COMODO/COMODO Internet Security/scanners/pkann.dll

/COMODO/COMODO Internet Security/scanners/rkdenum.dll

/COMODO/COMODO Internet Security/scanners/rkdhive.dll

/COMODO/COMODO Internet Security/scanners/rkdntfs.dll

/COMODO/COMODO Internet Security/scanners/script.cav

/COMODO/COMODO Internet Security/scanners/white.cav

/COMODO/COMODO Internet Security/repair/guard32.dll

/COMODO/COMODO Internet Security/repair/7za.dll

/COMODO/COMODO Internet Security/repair/cavscan.exe

/COMODO/COMODO Internet Security/repair/cavshell.dll

/COMODO/COMODO Internet Security/repair/cfp.exe

/COMODO/COMODO Internet Security/repair/cfpconfg.exe

/COMODO/COMODO Internet Security/repair/cfpupdat.exe

/COMODO/COMODO Internet Security/repair/cmdagent.exe

/COMODO/COMODO Internet Security/repair/cmdcomps.dll

/COMODO/COMODO Internet Security/repair/cmderd.sys

/COMODO/COMODO Internet Security/repair/cmdGuard.sys

/COMODO/COMODO Internet Security/repair/cmdhlp.sys

/COMODO/COMODO Internet Security/repair/cmdhtml.dll

/COMODO/COMODO Internet Security/repair/cmdinstall.exe

/COMODO/COMODO Internet Security/repair/common.cav

/COMODO/COMODO Internet Security/repair/crashrep.exe

/COMODO/COMODO Internet Security/repair/default.set

/COMODO/COMODO Internet Security/repair/dosmz.cav

/COMODO/COMODO Internet Security/repair/dunpack.cav

/COMODO/COMODO Internet Security/repair/extra.cav

/COMODO/COMODO Internet Security/repair/framework.dll

/COMODO/COMODO Internet Security/repair/guard64.dll

/COMODO/COMODO Internet Security/repair/gunpack.cav

/COMODO/COMODO Internet Security/repair/heur.cav

/COMODO/COMODO Internet Security/repair/inspect.sys

/COMODO/COMODO Internet Security/repair/mach32.dll

/COMODO/COMODO Internet Security/repair/mem.cav

/COMODO/COMODO Internet Security/repair/msica.dll

/COMODO/COMODO Internet Security/repair/pkann.dll

/COMODO/COMODO Internet Security/repair/platform.dll

/COMODO/COMODO Internet Security/repair/rkdenum.dll

/COMODO/COMODO Internet Security/repair/rkdhive.dll

/COMODO/COMODO Internet Security/repair/rkdntfs.dll

/COMODO/COMODO Internet Security/repair/signmgr.dll

Webroot SecureAnywhere Complete

ASLR/DEP seem to be enabled on all three executable files (including the Chrome extension). Can’t seem to find any others.   If anyone has more info please share.

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,