Configuring Grsecurity Is Easier – New Autoconfig

My previous guide on configuring Grsecurity isn’t too difficult to follow, but if messing with those settings is more than you want to do, there’s an autoconfig option.

Open your configuration with make menuconfig and then traverse via:

Security options –>

Grsecurity –>

Configuration Method

 

Set configuration method to automatic.

config1

 

You can state whether you need to run it in a VM, whether it’s for a server or desktop, whether you prioritize performance over security, and your special groups. And you can ‘tweak’ it from there, with the Customize Configuration option.

It takes seconds to configure the kernel with Grsecurity.

For my old guide see: http://www.insanitybit.com/2012/05/31/compile-and-patch-your-own-secure-linux-kernel-with-pax-and-grsecurity/

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.

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.

Secure Boot In Fedora – Hope?

A recent article highlights the new world of secure-boot Windows computers and how Fedora 18 will be arriving very much around the time of Windows 8.

Secure Boot is a security implementation that aims to prevent untrusted code from running before the OS loads. It’s a powerful new security method and it directly attempts to prevent multiple different attacks that can be (and have already been) used by malware to dig deep into the system.

Implementing Secure Boot in Linux is actually really great. It’s Linux so you know, without a doubt, that limiting a users freedom is absolutely out of the question and they’ll take security to the highest level possible. Users can still use their own kernels (they just have to sign the kernel themselves, it complicates things but not a ton) so don’t worry, you don’t need to turn it off to maintain the same level of freedom as always.

After all of the entirely unjustified hype that Windows 8 Secure Boot would kill Linux or that new hardware would lock you out it’s really great to see that the Distros are working on incorporating this feature and making use of it to the full extent. I do wish it were under better circumstances instead of having to fight not to be locked out of hardware… but it’s not nearly as terrible as what it could have been and we get a neat security feature out of it.

So while Linux has had its hand forced in this situation we do gain a really neat security feature.

It’s lukewarm but I’m happy.