Hardened Ubuntu Kernel

Discussion in 'all things UNIX' started by Hungry Man, Apr 21, 2012.

Thread Status:
Not open for further replies.
  1. Hungry Man
    Online

    Hungry Man Registered Member

    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
    Last edited: Apr 23, 2012
  2. Mrkvonic
    Offline

    Mrkvonic Linux Systems Expert

    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
  3. Hungry Man
    Online

    Hungry Man Registered Member

  4. guest
    Offline

    guest Guest

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

    Hungry Man Registered Member

    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.
  6. NGRhodes
    Offline

    NGRhodes Registered Member

  7. Hungry Man
    Online

    Hungry Man Registered Member

    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.
    Last edited: Apr 21, 2012
  8. Hungry Man
    Online

    Hungry Man Registered Member

    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?
  9. NGRhodes
    Offline

    NGRhodes Registered Member

    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) ?
  10. NGRhodes
    Offline

    NGRhodes Registered Member

    What source are you using for your Kernel ?
  11. Hungry Man
    Online

    Hungry Man Registered Member

    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.
    Last edited: Apr 21, 2012
  12. NGRhodes
    Offline

    NGRhodes Registered Member

    Ubuntu 11.10 64bit, totally standard.

    Why have you chosen grsec over apparmour ?
  13. Hungry Man
    Online

    Hungry Man Registered Member

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

    NGRhodes Registered Member

    Why would I use GrSec as well as apparmor, what additional security does it offer ?
  15. Hungry Man
    Online

    Hungry Man Registered Member

    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.
  16. Hungry Man
    Online

    Hungry Man Registered Member

    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.
  17. NGRhodes
    Offline

    NGRhodes Registered Member

    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
  18. Hungry Man
    Online

    Hungry Man Registered Member

    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.
  19. NGRhodes
    Offline

    NGRhodes Registered Member

    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.
  20. Hungry Man
    Online

    Hungry Man Registered Member

    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.
  21. BrandiCandi
    Offline

    BrandiCandi Guest

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

    Hungry Man Registered Member

    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.
    Last edited: Apr 23, 2012
  23. Hungry Man
    Online

    Hungry Man Registered Member

    Last edited: Apr 23, 2012
  24. Hungry Man
    Online

    Hungry Man Registered Member

  25. NGRhodes
    Offline

    NGRhodes Registered Member

Thread Status:
Not open for further replies.