Ubuntu 13.10 And mprotect() Restrictions

For a while I’ve had to keep the Restrict mprotect() option in PaX disabled because it wasn’t compatible with certain programs. It was kind of a huge pain to deal with for that reason. But I’ve finally taken the 30 seconds to just deal with it and I’ll post how.

The program that has the biggest issue with the restrictions is Unity, the program that handles your user interface on Ubuntu. So, we need to kill Unity so that we can use the paxctl program to disable mprotect restrictions.

Keep in mind that you need to enable CONFIG_PAX_PT_PAX_FLAGS in your kernel config for this.

1) Download paxctl

A simple ‘apt-get install paxctl’ is enough here.

2) Kill Unity and Xorg

This is the annoying part. Xorg just restarts every time it’s killed. So you have to run the following command:

service lightdm stop

And then hit ctrl + alt + F4.

You should now have a terminal.

3) Apply flags

Run:
paxctl -c /usr/bin/unity
paxctl -m /usr/bin/unity

Now you can reboot and your UI should work. You’ll have to do this for a few programs (like Chrome) as well.
From the Grsecurity wiki on mprotect() restrictions:

Enabling this option will prevent programs from
– changing the executable status of memory pages that were
not originally created as executable,
– making read-only executable pages writable again,
– creating executable pages from anonymous memory,
– making read-only-after-relocations (RELRO) data pages writable again.

You should say Y here to complete the protection provided by
the enforcement of non-executable pages.

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.

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

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 checksec.sh. Run the following command: (You must first set the file as executable)

./checksec.sh –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

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.

Patching

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:

http://www.canonical.com/about-canonical/contact

 you have suggestions for canonical.com or ubuntu.com, please email us atwebmaster@canonical.com or webmaster@ubuntu.com.

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.

Why Grsecurity Is Always On Top

Earlier today there was an excellent blog post about bypassing SMAP (or KERNEXEC, for the PaX implementation via the Grsecurity patch) in the Linux kernel using JIT spraying. SMAP is the latest mitigation technique implemented in hardware by intel’s Ivy Bridge processors. The goal of SMAP is to prevent “supervisory code” AKA the kernel from executing pages that exist in userland.

JIT’d code doesn’t have the same exploit mitigation techniques applied to it because of its nature – having to be executable, for example. It just so happens that there’s JIT’d code in the Linux kernel, the Berkley Packet Filter (used for Chrome’s seccomp sandbox) and that you can hack your way into the kernel through it.

It’s a great demonstration of JIT spraying to bypass modern mitigation techniques and even though a full PaX/Grsecurity enabled kernel almost certainly would have prevented it Brad Spengler decided to take it further – implementing a new mitigation to harden BPF against attack. Mind you he took about 30 minutes to do so.

This is why Grsecurity is at the forefront of security. The PaX team and Spender are consistently providing mitigation techniques that work to remove entire classes of vulnerabilities.  Grsecurity/PaX has basically been ten steps ahead of every software security implementation, so watch that project if you want to know what defense is going to look like in a few years.

For what it’s worth there’s JIT’d code in the Windows kernel as well.

ATI Drivers 12.6 Support ASLR!

I’m very pleased to announce that ATI is now supporting ASLR for its 12.6 beta drivers. This is great news as I’ve blogged about this stupid design decision in the past.

Thanks commenter tedbrogan for bringing this to my attention.

With the GPU Drivers now supporting ASLR many systems will be able to enable ASLR system wide. ASLR depends heavily on all areas of an address space being randomized so this is fairly significant.

Get your ATI Drivers here:

http://support.amd.com/us/gpudownload/Pages/index.aspx

Universal ASLR Bypasses And How To Solve Them

Address Space Layout Randomization is an exploit mitigation technique that focuses on preventing Return Oriented Programming attacks. It’s become one of the “must have” tools for a secure program (like DEP) and it’s preset in all modern user-oriented operating systems.

Mitigating ROP is pretty important as most modern exploits take advantage of it. And ASLR would be entirely effective in an ideal world where every single part of address space is randomized and 64bit address space is impossible to bruteforce and heapspray doesn’t exist. We don’t live in that world and there are universal ASLR bypasses for Windows and Linux, heapspray does exist, and the majority of users are stuck in a 32bit address space (and 64bit vanilla ASLR isn’t necessarily impossible to bruteforce).

Windows is actually pretty on top of things with ASLR (as of Windows 8) and /FORCEASLR but there’s always going to be a way around it (unless some things seriously change.)

So what’s the answer?

Well, for non-performance critical applications perhaps a solution like Gadgetless Binaries would be a viable option. Gadgetless binaries would compile code in such a way that an attacker would be unable to make use of static address space instructions to form their attack.

There is a performance hit here so I’m not saying to compile everything with it, but for security critical applications why not? There are specific areas of Windows address space that are loaded in the same exact place every time – why not compile that area with gadgetless binaries and avoid situations like this?

There’s also a somewhat less effective In-Place Code  Randomization technique and even less effective (though still welcome) EAF, which is what Microsoft has implemented.

Perhaps I’m just missing something. Maybe this would require paying out or some such thing but it seems like a great idea to me as ASLR isn’t going to solve every problem. At least not with current implementations (outside of PaX ASLR, which makes use of many other features via Grsecurity to prevent attacks against ASLR).

Sources:

http://iseclab.org/papers/gfree.pdf

Why I Won’t Be Buying ATI Again

I run a nice midrange laptop with a nice i5 520m, 8GB of RAM, a hybrid drive, and an ATI 5650.

The performance is really exactly as I’d expect, I can play the games I want to play and I can watch HD videos while I browser and talk to friends all at once without a stutter and without my computer burning up.

The GPU has performed admirably and I’m entirely happy with its performance.

But AMD for whatever reason (I guess performance) will not work with PAX or full system ASLR. There are actually buffer overflows in the code that prevent me from turning ASLR on to the full extent that I’d like and because of the hardcoded address space I can’t (at least on Windows) turn ASLR to anything other than “Application Opt-In.”

That’s really not acceptable. GPU security issues aren’t super new and they’re plenty talked about. I get that in the past it wasn’t a priority, of course. But things have changed. We have OpenGL now and we have the GPU integrated into virtually every process. The GPU isn’t just about games (which are also now online) it’s used in everything… like my browser (or this?), like Flash, my UI, and multiple other programs.

AMD/ATI, step it up. I may not be buying another system for years but if I were buying one tomorrow I’d go nVidia.

Compile And Patch Your Own Secure Linux Kernel With PaX and Grsecurity

The reason why Linux and open source will always be more secure than Windows is because you can build advanced security right in. This guide’s going to show you how to do that. I’ll be explaining how to compile your own kernel with PaX and Grsecurity patches. (I’m actually compiling 3.3.6 for myself but this guide covers 3.2.18.)

First let’s explain a few things…

What Is A Kernel?

Well, if you don’t know what a kernel is this guide is probably a bit too advanced but far be it from me to turn you away. The kernel is essentially the core of the operating system. It is the lowest level of software on the system running with the highest rights. Linux runs on “The Linux Kernel” and that kernel is common to all Linux distributions.

What Is PaX?

PaX is a series of patches that can be applied to the Linux kernel. These patches provide functionality and improvements to built in features such as ASLR (Address Space Layout Randomization), which help mitigate and deter exploits.

PaX features can be daunting so for a per-feature explanation see this link. I highly suggest you take a look at these features and research both PaX and Grsecurity so you can fully understand what they provide.

What Is Grsecurity?

Grsecurity is another series of patches that can be applied to the Linux kernel. These patches will allow changes to policy, provide a tool for RBAC, and add new policies. Grsecurity and PaX are built to work together and reinforce one another.

Why Are We Doing This?

Well, to get the most secure system that you can possibly get you’re going to want to start compiling your own kernel. The kernel is, for various reasons, where security belongs (more on this in future posts.) Now, on a default install of some distro like, say, Ubuntu you’re fairly secure and the tools already provided can be used to really lock the system down (think AppArmor) but if you’re looking to secure your system against sophisticated and targeted attacks PAX and Grsecurity are the way to go.

Keep in mind that the settings I use are for my own system. A server would be able to use more settings because it wouldn’t have to worry about, for example, the sound working.

You will also need to do this for new updates from kernel.org in order to get the latest security patches, among other things. Not even Grsecurity will keep an unpatched system safe.

So, since we’re done with the intro…

Setting Up Our System

Before we even download source code we need to make sure we have everything necessary to actually compile and configure our kernel. Let’s start by installing some software: (I’ll assume sudo/root for this guide.)

# apt-get install patch bin86 kernel-package build-essential libncurses5-dev gcc-*-plugin-dev

That’s (hopefully) everything you need to compile, package, and configure the kernel. (You may need to install gcc and plugins.)

Now let’s set up a working folder and cd to it.

# mkdir /usr/src/linux/

# cd /usr/src/linux/

That’s it for now.

Downloading The Linux Kernel And Patches

In this example I’ll be using the Linux Kernel 3.2.18 (the same steps will work for any kernel, just change the patches) and the Grsecurity patch that goes along with it. I’m assuming you’re still in /usr/src/linux/.

# wget https://grsecurity.net/stable/grsecurity-2.9-3.2.18-201205301835.patch

# wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.18.tar.bz2

Once the download has completed you can extract linux-3.2.18.tar.bz2 to ./linux-3.2.18.

Patching The Kernel

This part is fairly simple, move to your new linux-3.2.18 folder and patch.

# cd ./linux-3.2.18

# patch -p1 < /usr/src/linux/grsecurity-2.9-3.2.18-201205301835.patch

This should patch the kernel without any interaction necessary.

Configuring The Kernel

(note: I am taking screenshots of a 3.3.6 kernel with my own configuration, yours may vary. Once size does not fit all – do research!)

#make menuconfig

You’ll be brought to this screen:

Note: If you want to enable KERNEXEC you must go to Processor Features and disable Xen/Paravirtualization.

Navigate (arrow keys) to Security Options and hit ‘Enter’ and…:

Configuring Grsecurity:

As you can see there are many options here. You can use preconfigured options (Low, Medium, High) or, as I suggest, Custom.

The following settings are suggestions that work for me. They can make or break systems depending on usage. A server might need completely different settings, for example. You’ll probably be compiling a few kernels just to see what breaks when.

Memory Protections:

[*] Deny reading/writing to /dev/kmem, /dev/mem, and /dev/port
[  ] Disable privileged I/O
[*] Harden ASLR against information leaks and entropy reduction
[*] Deter exploit bruteforcing
[*] Harden module auto-loading
[*] Hide kernel symbols
[*] Active kernel exploit response

Role Based Access Control (RBAC): I’ll post later about configuring RBAC.

[  ] Disable RBAC system
[*] Hide kernel processes
(3) Maximum tries before password lockout
(30) Time to wait after max password tries, in seconds

Filesystem Protections:

[*] Proc restrictions
[*] Restrict /proc to user only
[*] Additional restrictions
[*] Linking restrictions
[*] FIFO restrictions
[  ] Sysfs/debugfs restriction     -Breaks Sound on Ubuntu
[  ] Runtime read-only mount protection   -For servers, not users.
[*] Chroot jail restrictions
[*] Deny mounts
[*] Deny double-chroots

[*] Deny pivot_root in chroot

[*] Enforce chdir(“/”) on all chroots
[*] Deny (f)chmod +s
[*] Deny fchdir out of chroot
[*] Deny mknod
[*] Deny shmat() out of chroot
[*] Deny access to abstract AF_UNIX sockets out of chroot
[*] Protect outside processes
[*] Restrict priority changes
[*] Deny sysctl writes

[*] Capability restrictions

Kernel Auditing:

Your choice, this is more useful for servers. As a user I don’t need any of this.

Executable Protections:

[*] Dmesg(8) restriction
[*] Deter ptrace-based process snooping
[*] Require read access to ptrace sensitive binaries
[*] Enforce consistent multithreaded privileges
[*] Trusted Path Execution (TPE)
[*] Partially restrict all non-root users -This is one option that I use. It may break things and it’s not a critical feature so you may consider removing it.

Network Protections:

[*] Larger entropy pools
[*] TCP/UDP blackhole and LAST_ACK DoS prevention
[  ] Socket restrictions

SysCtl Support:

[  ] Sysctl support
[  ] Turn on features by default

Configuring PAX:

As with Grsecurity we’re presented with quite a few options. PAX settings can very easily break things so my settings will likely vary from what your settings could be. I will note specific areas where there are known conflicts.

For details on PaX features see this link.

PaX Control:

[  ] Support soft mode By leaving this off we have PaX system wide.
[  ] Use legacy ELF header marking
[  ] Use ELF program header marking
[  ] Use filesystem extended attributes marking

Non-Executable Pages:

[*] Enforce non-executable pages
[*] Paging based non-executable pages
[*] Emulate trampolines
[*] Restrict mprotect() This will break X.
[  ] Use legacy/compat protection demoting (read help)
[  ] Allow ELF text relocations (read help)

[*] Enforce non-executable kernel pages (Requires  you disabled Xen)
Return Address Instrumentation Method (bts) —>

Address Space Layout Randomization:

[*] Address Space Layout Randomization
[*] Randomize kernel stack base
[*] Randomize user stack base
[*] Randomize mmap() base

Miscellaneous Hardening Features: (Note: Users of ATI SPUs must use my settings here. Users with other GPUs should enable all ** settings.)

[*] Sanitize all freed memory
[*] Sanitize kernel stack
[*] Prevent various kernel object reference counter overflows  **
[*] Harden heap object copies between kernel and userland  **
[*] Prevent various integer overflows in function size parameters

**As of version 12.8 the closed source ATI FGLRX drivers are compatible with the above. Earlier versions will NOT work.

Other Security Settings

Exit your PaX options and go back to the security settings.

Set ” Low address space for LSM to protect from user allocation” to 65536 or 32768:

This is the portion of low virtual memory which should be protected
from userspace allocation. Keeping a user from writing to low pages
can help reduce the impact of kernel NULL pointer bugs.

For most ia64, ppc64 and x86 users with lots of address space
a value of 65536 is reasonable and should cause no problems.
On arm and other archs it should not be higher than 32768.
Programs which use vm86 functionality or have some need to map
this low address space will need the permission specific to the
systems running LSM.

Time To Compile And Install

(Note: You may want to see the last section ‘Other Tips’ before you compile.)

# make-kpkg clean

# make-kpkg --initrd --append-to-version "grsec1.0" kernel_image

The above command might give you an error in which case you’ll need to type it out. It’s a wordpress issue where it combines the –‘s.

Compiling will take a while. Probably a half hour, potentially multiple hours depending on the hardware. When you’re done there will be a package in /usr/src/linux.

# cd /usr/src/linux

# dpkg -i ./<name.of.deb>

Reboot into the new kernel and that’s it.

It’s a lot of work to set it up but it should only take you a few minutes after the first time. Compiling is what takes the longest but it can be done in the background.

If something breaks just boot into the last kernel you used. Simple.

Other Tips

Since you’re taking the time to compile this thing you may as well get the most out of it. I suggest you go through the settings and disable any drivers not related/ enable or disable features.

You should also open /usr/src/linux/linux-3.2.18/makefile and find the line:

# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments

And have the following line as: (add the -march=native -pipe -mtune=native)

KBUILD_CPPFLAGS += $(KCPPFLAGS) -march=native -pipe -mtune=native

pipe will speed up compile time significantly for systems with lots of RAM. march=native will optimize the kernel for your specific CPU. Don’t use -march=native if you are compiling for another system with a different CPU (same for mtune).

Take the time to disable drivers that you won’t use. It’ll speed up compile time and produce a smaller kernel.

Highlights

The highlights of this new kernel are:

1) Improved ASLR

2) RBAC

3) Hardened Chroots (if you use Chromium or Google Chrome the sandbox makes use of Chroots so you’ve just made it more secure.)

4) Exploit bruteforcing is much harder

5) A generally more secure system with stricter policies and checks

6) Optimized kernel if you followed the “notes.”

This was a long post so if I’ve left anything out or misrepresented something leave a comment and let me know. RBAC is worth its own full post so I’ll get to that later (setting it up on any user-oriented OS is difficult.) For now you can see this wiki page to learn how to set RBAC up, but it’s not so simple.

Sources:

http://www.howtoforge.com/hardening-the-linux-kernel-with-grsecurity-debian

http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml

https://en.wikibooks.org/wiki/Grsecurity/Print_version