Hardened Ubuntu Kernel

I've been compiling myself for my own use but they should work for other people who are interested in a more secure OS. I'll upload versions as I compile them.

Got the 3.2.15 kernel compiled with the following:

Grsec:

Memory Protections:
Deny reading/writing to /dev/kmem, /dev/mem, /dev/port
Harden ASLR against information leaks and Entropy Reduction
Deter exploit bruteforcing
Harden module auto-loding
Hide kernel symbols
Active Kernel exploit response

RBAC:
Hide kernel processes
default password

Filesystem restrictions:
Proc restriction
Linking restrictions
FIFO restrictions
All Chroot jail restrictions

No kernel auditing:


PAX:
Pax Control: None

Executable Pages:
Enforce nonexec pages
Paging based nonexec pages

ASLR:
Randomize Kernel Stack Base
Randomize User Stack Base
Randomize mmap() base

Misc:
Prevent various kernel object referene counter overflows
Harden heap object copies between kernel and userland


This is working pretty well for me. I'm compiling with -O2 optimizations and a few harder settings. (sanitize kernel stack for example)

It's not optimized for my CPU at all so it should work on any Ubuntu computer, though keep in mind that I'm on 12.04. It might work on other distros as well. 64bit is necessary though.

Just dpkg -i /path/ to install. And if it breaks your computer don't blame me. I broke it 10x but thankfully you can always boot into an old kernel.

v1.0
http://www.2shared.com/file/pxo2Pack/linux-image-3215grsec10-grsec_.html

v1.1 Same as above but with optimized -O2 flag
http://www.2shared.com/file/dnY5g9sr/linux-image-3215grsec11-grsec_.html

v1.2 will be -O2 flag + more kernel protections
compiling 1.2 now

v1.4 -02 flag and ATI GPU compatible
http://dl.dropbox.com/u/75308989/li...c_3.2.16grsec1.4-grsec-10.00.Custom_amd64.deb

 

One simple question: why?
Are you aware of all the implications of things you disabled?
Like hiding kernel symbols, /dev/mem access and so forth.
Mrk

 

Yes, I am. There's a nice wiki page:
https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options

It explains all of the objects and I understand what nearly all of them do.

Why? Because I can, mostly. Compiling the kernel was a learning experience and the end-result is an optimized and hardened kernel.

 

I'm curious, with this thing can you still install updates, like security fixes to new vulnerabilities etc?

 

I'll have to compile and apply patches myself for the kernel or recompile the kernel with the patches built in. I'll still be able to update the 3rd party software (such as Unity, browser, im clients etc) through apt-get.

I am potentially foregoing rapid patch management so that I can instead make use of kernel ASLR and various other techniques. I'd rather have those techniques though.

edit: Right now it's 3.2.15. That meanas kernel 3.2 and patch .15 I believe. So I'll just update when patch .16 is released.

 

How has the security of you system as a result of these changes ?

FYI Ubuntu hardens the kernel as standard https://wiki.ubuntu.com/Security/Features.

Cheers, Nick

 

There are kernel security options and then the PaX and Grsec security options. I've changed nothing in the kernel security otpions - they're the same as what you'd normally get. I've only added the ones that PaX and grsec provide.

Everything in PaX is enabled on boot (you can configure per program if you compile for it, I have not since it's less secure and takes more work) and you have to set grsec up yourself.

You can test yourself with paxtest to see how vulnerable you are:
http://manpages.ubuntu.com/manpages/hardy/man1/paxtest.1.html
https://grsecurity.net/~paxguy1/

I think paxtest is 32bit only though, unfortunately.

edit: Actually I got paxtest working.

 

Just FYI this is my output. The reason some of these are vulnerable has to do with the areas I did not check for compatibility reasons (restricting mprotect, and 2 other flags) but I'm testing them (or will be soon.) I do not believe that mprotect restrictions are actually that beneficial but they can potentially break programs.


edit: Nick, source for what?

 

My output:

Code:

PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Mode: Blackhat
Linux Peregrine 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect)                : Vulnerable
Executable data (mprotect)               : Vulnerable
Executable heap (mprotect)               : Vulnerable
Executable stack (mprotect)              : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments                   : Vulnerable
Anonymous mapping randomisation test     : 9 bits (guessed)
Heap randomisation test (ET_EXEC)        : 14 bits (guessed)
Heap randomisation test (PIE)            : 16 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (PIE)      : 9 bits (guessed)
Shared library randomisation test        : 10 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 19 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 19 bits (guessed)
Return to function (strcpy)              : Vulnerable
Return to function (memcpy)              : Killed
Return to function (strcpy, PIE)         : Vulnerable
Return to function (memcpy, PIE)         : Killed

How does your kernel improve things (your randomisation seems worse) ?

 

What source are you using for your Kernel ?

 

I'm using kernel.org patched with the appropriate patches here: http://kernel.ubuntu.com/~kernel-ppa/mainline/

What OS are you using? If you're using one with execshield, which Ubuntu does not have, the restuls will be different.

edit: latest kernel:

Code:

Mode: Kiddie
Linux colin-vaio 3.2.15grsec1.2-grsec #5 SMP Sat Apr 21 16:37:30 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect)                : Vulnerable
Executable data (mprotect)               : Vulnerable
Executable heap (mprotect)               : Vulnerable
Executable stack (mprotect)              : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments                   : Vulnerable
Anonymous mapping randomisation test     : 9 bits (guessed)
Heap randomisation test (ET_EXEC)        : No randomisation
Heap randomisation test (PIE)            : 12 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (PIE)      : 8 bits (guessed)
Shared library randomisation test        : 10 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 10 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 10 bits (guessed)
Return to function (strcpy)              : Vulnerable
Return to function (memcpy)              : Return to function (strcpy, PIE)         : Vulnerable
Return to function (memcpy, PIE)         : 
colin@colin-vaio:~$ sudo paxtest blackhat /home/colin/Downloads/test2.txt
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Writing output to /home/colin/Downloads/test2.txt
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Mode: Blackhat
Linux colin-vaio 3.2.15grsec1.2-grsec #5 SMP Sat Apr 21 16:37:30 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect)                : Vulnerable
Executable data (mprotect)               : Vulnerable
Executable heap (mprotect)               : Vulnerable
Executable stack (mprotect)              : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments                   : Vulnerable
Anonymous mapping randomisation test     : 9 bits (guessed)
Heap randomisation test (ET_EXEC)        : No randomisation
Heap randomisation test (PIE)            : 8 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (PIE)      : 8 bits (guessed)
Shared library randomisation test        : 10 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 10 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 10 bits (guessed)
Return to function (strcpy)              : Vulnerable
Return to function (memcpy)              : Killed
Return to function (strcpy, PIE)         : Vulnerable
Return to function (memcpy, PIE)         : Killed

colin@colin-vaio:~$ 

Still no restrict mprotect. Most of the "vulnerables" are for that.

 

Ubuntu 11.10 64bit, totally standard.

Why have you chosen grsec over apparmour ?

 

It's not one or the other. You can use both at the same time. Grsec is not a LSM.

 

Why would I use GrSec as well as apparmor, what additional security does it offer ?

 

They're just different. Apparmor is a per-process MAC whereas RBAC is role based. So whereas I liimit an application with apparmor I limit the user with RBAC.

GRsec also provides PaX, which hardens the kernel in various ways.

 

Ok. I was using the wrong version fo paxtest... that explains the low entropy lol 32bit paxtest on 64bit OS isn't doing it right.

 

Not trying to awkward BTW, just trying to get an understanding of why you have done what you have done.

Yes PaX can be useful, but I thought the hardening offered was more suited to servers than desktop apps ?

Apparmor allows user level granularity through MLS, how does role based compare/contrast of GRSec ?

Cheers, Nick

 

No, not awkward. Happy to discuss.

PaX is definitely suited to servers, which are under direct attack more often. But everything that applies to PaX can apply to users. For example, one part of grsecurity is that chroots are hardened, making escapes easier. Chrome actually uses chroot for its sandbox, which means that it is now more difficult to bypass. Just one example.

Grsec's RBAC isn't something I'm an expert on, I haven't gotten very far.

But... apparmor will restrict something like Chrome, or Pidgin. RBAC restricts the entire user account and even potentially the admin account. I can make it so that even if the hacker gets root they're restricted and need my grsec password to do what they want to do.

 

Cheers for the info.

Nice to see security discussions on Linux. It usually works well as default so I don't have much Linux specific security, I only have worked on securing PHP (usually just config settings, no patched builds) and locking down mysql to local network/machine access only.

Cheers Nick.

 

Unfortunately the geniuses at ATI don't make ASLR compatible drivers so I'm considering just coming up with a new kernel with lighter ASLR but I need to get back to studying and I'm not going to waste time with that.

It was a learning experience at least. To anyone who wants to use the posted kernels, they work great, but if you don't use the open source ATI drivers they'll kill your machine.

 

Interesting. You should pen test your system with backtrack or something when it's all done, see if you're really more secure.

 

If I ever get the system set up maybe I'll try to test out some exploits on programs/ the OS.

Due to ATI being annoying I'm stuck on the regular kernel, which is a bit lacking.

edit: I've found workarounds for ATI.

 

I've compiled a version that works with ATI drivers. That's what I'm now using. It's -O2 optimized and uses full ASLR but I've had to deactivate the PAX settings that check for specific types of overflows.

I'll upload it.

http://dl.dropbox.com/u/75308989/li...c_3.2.16grsec1.4-grsec-10.00.Custom_amd64.deb

 

http://www.trapkit.de/tools/checksec.html

Can someone running a default distro run this?

 

I get a syntax error :|