A Quick and Dirty Guide To Kernel Hardening with GrSecurity

2007-12-20T15:18:00.000-05:00

The combination of the Linux kernel and GNU packages has always been regarded as a secure operating system, but can it be more secure? Kernel hardening is the answer to tightening up the Linux backbone. GrSecurity, a kernel patch for Linux, is one of the more popular approaches. After applying this patch and compiling a fresh kernel, your system will have a plethora of new security features.

The most significant feature is the addition of a role-based access control system (RBAC) that monitors what each user can execute based on their role and denies execution if they overstep their pre-defined rules. Other useful features include ip-based rules, extensive chroot restrictions, address space modification restrictions (PaX), auditing/logging features and /proc and dmesg anti-leak features. A full feature list can be found at the Grsecurity homepage.

Installing Grsecurity:

First we need to download the Linux kernel and Grsec patch.

$ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.19.2.tar.gz
$ wget http://grsecurity.net/grsecurity-2.1.10-2.6.19.2-200701222307.patch.gz

For your convenience, the PGP keys are located at:

http://GRSecurity.net/spender-gpg-key.asc
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.19.2.tar.gz.sign

Move the kernel and patch into the /usr/src directory.

$ su -c “cp linux-2.6* /usr/src; cp grsec* /usr/src”

Extract the kernel and patch (you need to be in root since you're working in /usr/src).

$ su
# tar zxvf linux-2.6.19.2.tar.gz
# gunzip grsecurity-2.1.10-2.6.19.2-200701222307.patch.gz
# patch -p0 < grsecurity-2.1.10-2.6.19.2-200701222307.patch

Start with the kernel configuration.

# make clean
# make mrproper
# make menuconfig

Choose all of the options that are required for your hardware, or use “make oldconfig” and se an old configuration file. When you arrive at the “GRSECURITY” section, enable it by hitting the spacebar. You are now prompted with an array of security features. Building a custom scheme is as easy as selecting a few features, or select a pre-defined security level based on your needs. Taylor Merry created a fantastic list that shows what each level of security provides. His table is listed below:

Low Security:

linking restrictions
fifo restrictions
random pids
enforcing nproc on execve()
restricted dmesg
random ip ids
enforced chdir("/") on chroot< /li>

Medium Security (includes all of the Low Security options):

random tcp source ports
altered ping ids
failed fork logging
time change logging
signal logging
deny mounts in chroot
deny double chrooting
deny sysctl writes in chroot
deny mknod in chroot
deny access to abstract AF_UNIX sockets out of chroot
deny pivot_root in chroot
denied writes of /dev/kmem, /dev/mem, and /dev/port• /proc restrictions with special gid set to 10 (usually wheel)
address space layout randomization

High Security (includes all of the Low and Medium Security options):

additional /proc restrictions
chmod restrictions in chroot
no signals, ptrace, or viewing processes outside of chroot
capability restrictions in chroot
deny fchdir out of chroot
priority restrictions in chroot
segmentation-based implementation of PaX
mprotect restrictions
removal of /proc//[maps|mem]
kernel stack randomization
mount/unmount/remount logging
kernel symbol hiding(18)

Outside of the options in these categories are a few additional options that can be enabled manually:

PaX: PAGEEXEC
PaX: EMUTRAMP
PaX: EMUSIGRT
PaX: Disallow ELF text relocations (DANGEROUS)
Disable privileged I/O (should not use with XFree86)
Hide kernel processes
Allow a user group access to /proc
Auditing options
Set up a single group that is the only one audited
Exec logging
Log execs within chroot
Chdir logging
IPC logging
Trusted path execution
Socket restrictions
Sysctl support
Netfilter Configuration: stealth match support(18) *1

For personal computers, I select “Low security” and enable all of the logging and auditing features. For servers and mission critical machines, I start with “Medium security” and add additional elements based on my own discretion.

After you have selected all of the necessary options, lets compile the kernel.

# make modules modules_install bzImage

Finally, copy the new kernel into your /boot directory and adjust your bootloader to load the new kernel. Your new kernel will be located in "usr/src/linux/arch/i386/boot/." At this point, you now have a Linux kernel with copious amounts of added security and protection.

Check back soon because our next article will show you how to use the role based access control system and how to compile programs to take advantage of the PaX address space modification restrictions!

References:
*1 Merry, Taylor. Linux Kernel Hardening. 18 November 2003

GrSecurity Homepage

PaX Homepage

Social Engineering is not just a definition!

2007-11-16T19:36:00.000-05:00

In modern day, you would assume that brute force hacking coupled with some known software flaws would be the easiest way to circumvent a security system. You’d be wrong. Why waste time pounding a server when you can just pick up the phone? The oldest trick in the book still reigns supreme. Take this conversation for an example:

"Hi Linda, this is Craig with IT. We are implementing a new password system where each password must contain 10 characters, with at least one number and one capital letter. What would you like me to set yours as? ... What is your old password for confirmation? ... Great, your new password should be active later this month."

Craig never worked for Linda's company, nor did he call from IT. Craig was an unethical hacker who just gained unauthorized access to her account. Why? Because a phone call is simple. Why spend hours poking for security holes when unsuspecting employees will just give you confidential information? This person-to-person deception is known as social engineering, produced through logical human flaws classified under cognitive biases.1

It seems social engineering and even physical security have become second to digital security. Firewalls, encryption, and public keys have saturated the market and our mind--making them top priority. Without educated employees, modern digital security is useless.

Take this actual event for example:

About three years ago, I was hired as a security consultant for a medium-sized company. I looked over their software, firewalls, and servers; everything was up to date and acceptable. There were a few small problems, but overall their physical and digital security schemes were acceptable in my book. The next step was to test their employees--the psychological aspect of my report.

Two weeks later, I sent my colleague whom they have never met before to their office. He walked up to the front desk, introduced himself to the receptionist, and said he was here for a security update. He instructed the secretary for her username, password, and a key to the server room. He was polite, smiled, and had a crisp business card from my company. She complied without question, and then he proceeded to enter each subsequent cubical, retrieving the username and password for each employee who was available.

My security report for them had three main sections: digital, physical, and psychological. The latter was labeled in big red letters, "Immediate action is required to prevent compromise!" About 12 hours later, I received a phone call from the IT manger. With a stern attitude, he exclaimed that if their servers were secure, there is no way they could be compromised. I responded slowly in a calm voice, "they can, because a young man walked into your office with nothing but a mere business card, and walked out with 55 passwords and a key to your server room."

After a long conversation, it was clear that their security policy needed to be updated, and more importantly, that their employees needed training...desperately. It took over two weeks to talk with every employee, numerous phony scam emails to keep each worker on their toes, and finally, I sent my young colleague back in. This time, the receptionist called me to confirm his identity, and photocopied his driver's license.

Well done I told her, well done.

So how does all of this pertain to you and your company? Talk to your employees--educate them. Offer and even require training sessions. Send emails to your employees asking for their password and/or confidential information. If they respond, tell them that they shouldn't! Probe them and always be testing! Make sure each and every person is aware of current and past scams, social engineering tricks, and safe practices.

You can have the most secure servers and firewalls, but if your employees just hand over confidential information, you are doomed from the start.

References
1 CSEPS Course Workbook, unit 3

8ciphers

A Quick and Dirty Guide To Kernel Hardening with GrSecurity

Social Engineering is not just a definition!