; Linux Kernel Hardening
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Linux Kernel Hardening

VIEWS: 106 PAGES: 11

Misc security dump

More Info
  • pg 1
									Linux Kernel Hardening

Anton Chuvakin, Ph.D. (anton@chuvakin.org)

WRITTEN: 2001

DISCLAIMER:

Security is a rapidly changing field of human endeavor. Threats we face literally change every day;
moreover, many security professionals consider the rate of change to be accelerating. On top of that, to be
able to stay in touch with such ever-changing reality, one has to evolve with the space as well. Thus, even
though I hope that this document will be useful for to my readers, please keep in mind that is was possibly
written years ago. Also, keep in mind that some of the URL might have gone 404, please Google around.



The article covers the issues of Linux hardening with specific focus

on kernel hardening and its use on production systems. Several kernel

hardening approaches and their usability are being analyzed.



Is Linux secure? The question is much less useful, than 'Is Linux

"securable"?' The answer to the latter is a definite "yes". "Being

securable" means that Linux can be made more secure (to whatever

degree necessary) by applying a clearly defined sequence of steps,

that always produces the same result, that can be automated and

applied to systems that were in operation for a long time. It would be

ideal to have the way to secure a system understandable by regular

system administrators without formal security training. However, the

last requirement might be pushing it a bit, since security will likely

always require expertise.



Linux can be made more secure by applying "system hardening". The are

many Linux hardening guides (such as

http://www.sans.org/infosecFAQ/linux/hardening.htm
http://www.enteract.com/~lspitz/linux.html

http://www.linuxsecurity.com/resource_files/documentation/QUICKSTART/index.html

http://www.linuxsecurity.com/resource_files/documentation/QUICKSTART-Redhat/index.html

) and utilities, such as Bastille linux (www.bastille-linux.org). The

latter automate the hardening process with detailed explanations on

each step. Hardened Linux distributions such as EnGarde Linux

(www.engardelinux.com) and Immunix (www.immunix.com) are also

available. Typical steps that are taken during the system hardening

include:



1. Minimizing installed software

2. Patching the system

3. Securing filesystem permissions and S*ID binaries

4. Improving login and user security

5. Setting some physical and boot security controls

6. Securing the daemons via network access controls

7. Increasing logging and audit information

8. Configuring vendor supplied security software (IDS, host firewall)



It is curious to note that hardening is not just fixing bad defaults

the vendors throw at users. It is believed, that vendors ship systems

with mostly open default setting based on customer feeback. Thus

hardening should be viewed not as "fighting the evil vendor", but

rather like optimizing the system based on local business and security

needs.



Hardening is also a great example of defense in depth. Such Linux
system will be much harder to crack and utilize for nefarious

purposes. There are examples of Linux servers running for years

without a successful penetration and with no firewall. Their

reliability is due to professionally hardened OS.



However, system hardening appears to be lacking in several

aspects. For example, buggy SUID programs and network application will

still give the attacker root and user access. If attacker gets "root",

there is positively no way to stop them from anything on a normal

Linux system. In addition, basic UNIX access controls will not stop

authorized system users from doing various bad things (port scanning,

accessing unauthorized resources, running password crackers or banned

network applications), which cannot be "access controlled" away

without rendering the system unusable. And while hardening, improved

logging, audit and intrusion detection will complicate rootkit

deployment by attackers, kernel-level rootkits can easily overcome

those preventive measures.



To combat these threats, kernel hardening is needed. Here it is

defined as enabling additional kernel-level security mechanisms to

improve the security of the system, while keeping system close to

traditional Linux.



What are some approaches to kernel hardening? Modern Linux kernel can

be tightened a bit securitywise without adding any new features or

patches. One can compile the kernel with no module support (most

kernel rootkits cannot function) and some security-related kernel
options can be turned on.



The more advanced approach is kernel patching to remove some

potentially dangerus behavior without adding any new securituy

features. The most well-known kernel security patch of this kinds is

Openwall (www.openwall.com/linux). It is released for Linux kernels

versions 2.0 and 2.2. While not providing any drastic security

improvements such as capabilities, it helps to solve several of the

important security flaws with Linux. Openwall patch provides the

following features:



 1. Non-executable user stack area: makes running buffer overflow

 exploits more difficult. Heap overflows will work under this

 protection.

 2. Secured /tmp: several attacks work by

 creating a symbolic link to an existing inaccessible file (such as

 /etc/password) and then abusing some

 SUID root program into writing into the file. This feature stops

 such attacks. It also prevents users from creating hard links to

 files they do not own.

 3. Restricted writes into unowned FIFOs (named pipes): it makes

 certain data spoofing attacks harder by now allowing users to write

 data to pipes they do not own

 4. Secure /proc: it prevents users from looking at the information

 for processes they do not own

 5. Special handling of default files descriptors for SUID

 binaries: it helps prevent some attacks against the file handles by
 SUID programs

 6. Several security-related improvements related to process memory

 space handling such as deallocating shared memory segments not

 associated with any process



As reported by the wuthor, the patch breaks some functionality in

applications such as databases. It should be deployed with great care

after testing on similar machines. See prject FAQ here

[http://www.openwall.com/linux/FAQ] to learn of many issues that can

arise. Openwall will protect the system from many stack overflow

exploits, but not from heap overflows overflows and stack overflows

written to bypass the patch. To install the patch download the kernel

(latest 2.2 kernel is 2.2.20) source and Openwall patch source, unpack

both (kernel should go into /usr/src/linux-2.2.20 and one can copy the

patch file "linux-2.2.20-ow1.diff" into the same directory as well),

then patch using the command:



cd /usr/src/linux

patch -p1 linux-2.2.20-ow1.diff



After this compile kernel as usual. If using the GUI kernel config, a

new menu for security configuration will appear:



[kh-fig1.jpg]



Now try some buffer overflows or the included stack test program.
To summarise, several features of Openwall (overflow and /tmp symlink

protection, while) make a nice addition to any system connected to the

network and should be implemented if increased security is desired.



The next approach in kernel hardening product analyzed is Linux

Intrustion Detection System (LIDS, http://www.lids.org). LIDS

introduces much more changes to Linux kernel and imposes some

restrictions upon use and amdinistration practices. LIDS is covered in

detail in this series of articles by Brian Hatch:

http://www.securityfocus.com/infocus/1496

http://www.securityfocus.com/infocus/1502

http://www.securityfocus.com/infocus/1510

http://www.securityfocus.com/infocus/1517



However, the control infertace for LIDS was changed somewhat. Thus the

focus will be on using LIDS and on interface changes.



LIDS has a somewhat misleading name since its focus is on prevention,

rather than detection of system problems and intrusions (LIDS will

dutifully record a violation after stopping it). LIDS is a patch to a

standard Linux kernel source that provides Mandatory Access Controls

(MAC) support for Linux. MAC enables higher levels of security than

standard UNIX Discretionary Access Control (DAC), since it allows more

fine-grained access control and protection of files from owner and

superuser. In fact, superuser loses a large portion of its powers on a

MAC-based system. LIDS can protect and hide files and processes (from

termination, change of priority and other factors), grant access
privileges on an individual basis (unlike standard Unix permissions)

and give programs special rights called capablityies (such as for raw

device access or pasword change). Its protection expands into the

kernel space as well and it will stop malicious kernel modules from

loading. In addition, it has build-in kernel port scan detector.



The LIDS philosophy is views Linux as a set of subjects and

objects. Subjects (programs) are given rights to access objects

(files, directories, devices, network) and to perform some operations

(capabilities, such as to reboot, to insert modules, to broadcast, to

bind ports, etc). The rights can also be restricted by time. For

example, logrotate may be granted WRITE access to system logs only

from 6:00am to 6:05 am, the rest of the time the log files are

APPERND-only. There is also a set of global capabilities.



To configure LIDS one should download a package from www.lids.org and

then run ./configure script included. Follow the prompts to patch the

kernel source, build LIDS tools and create sample configs. Then build

the kernel. The special new menu will appear:



[kh-fig2.jpg]

[kh-fig3.jpg]



Before rebooting one should configure LIDS rules using "lidsconf"

command. In the past users were supposed to manually edit

/etc/lids/lids.conf file, but now the frontend utility is provided.

LIDS does not run out of the box - you have to run the configuration
tool, since some permissions from sample files are not applicable for

every system and it might cause the system to fail at boot (for

example, if init is prevented from accessing system configuration

files). Plenty of useful and slightly outdated documentation is

available at http://www.lids.org



Some example commands follow:



lidsconf -D -s /usr/X11R6/bin/XF86_SVGA



removes X server from config file /etc/lids/lids.conf



lidsconf -A -s /usr/X11R6/bin/XFree86 -o CAP_SYS_RAWIO -j GRANT



adds new (version 4) X server to config file /etc/lids/lids.conf and

grant it the right to perform raw I/O.



After LIDS is configured, reboot your LIDS-protected system. Some

program will probably not run with LIDS configured. To archive maximum

security, one has to figure out the minimum necessary permissions for

each running program (especially those that access the network can be

tricky) and then configure LIDS to only allow those. It is done by

observing the system logs for LIDS reports about violations and then

allowing the actions and it does take considerable effort.



Overall, LIDS configuration requires in-depth knowledge of UNIX system

(files, processes, permissions, etc). And with each mistake the level
of protection is decreased, while apparently staying higher than wtih

no LIDS protection at all. LIDS protection feature set is very rich.



To summarise, LIDS is an excellent security tool if one is willing to

invest time in learning its principles, then functionality, then

interface and after all configuring the system programs to run under

with LIDS securely. LIDS is definitely not a "shoot-and-forget" weapon

in security arsenal unless you have somebody (like your distribution

vendor or a consultant) to configure the system for you. For example,

EnGarde Linux distribution is built around LIDS.



There are several other kernel patches aimed at increasing security

(Medusa[http://medusa.fornax.sk],

LoMaC[http://opensource.nailabs.com/lomac/], RSBAC

[http://www.rsbac.org], NSA SELinux [http://www.nsa.gov/selinux]

etc). They all implement some model of Mandatory Controls. Other tools

modify kernel to log all set*id() system calls to augment the audit

information. GRsecurity (www.grsecurity.net) introduces a large set of

kernel 2.4 security patches, that incorporate openwall patch,

increased autit logging and many others. Separate defensive kernel

modules (StJude, http://sourceforge.net/projects/stjude) were written

to protect Linux system from exploits due to buggy sopftware by

restricting what running processes can do. There are simply too many

tools related to kernel hardening to list.



What are the problems with kernel hardening?
First, what does kernel hardening aim to achive? Greater security. But

does having all the MAC features, capabilities, restricted this and

that gives one a system that is less likely to fall victim to abuse,

either by mailicous hacker or by insiders? No, not unless the system

is configured properly. Thus having security-enhanced kernel might

tend to provide a false sense of security (just like companies that

procured firewalls felt they are "safe" now). That leads to the second

problem: kernel hardening is hard. While installing LIDS, Openwall

patch, or other MAC solutions is relatively easy (if one has

experience compiling and patching the kernel, that is), managing the

system with those security packages is anything but.



Even if those unsurmountable tasks of proper setu and maintainance are

completed, the system can still be compromised. Recently a serious bug

was discovered in LIDS by TESO

(http://www.lids.org/advisory1.txt.html), that might lead to a system

breach. It is well-known, that security software contains bugs as

well. In addition, kernel level protection can be bypassed if an

attacker manages to boot the system with her own kernel (not an easy

task on a properly hardened system).



So is kernel hardening a toy for geeky control freaks who enjoy

writing lengthy access control lists and denying rights to users? No,

it is a valid security tool. However, due to its complexisty it should

only be deployed in cases where a clear need for increased security

and expertise for properly installing and, which is more important,

effectively managing the secure systems are present. It is also highly
desirable that the system configurations do not change often such as

for appliance -type servers (where the default secure setup is created

and upgraded by the vendor via a one-time investment of effort). In

light of this, while system hardening should be performed on all

servers and workstations connected to the network, kernel hardening is

more appropriate for high-security, slow-changing environments.

ABOUT THE AUTHOR:

This is an updated author bio, added to the paper at the time of reposting in 2010.

Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert in the field of log
management and PCI DSS compliance. He is an author of books "Security Warrior" and "PCI Compliance"
and a contributor to "Know Your Enemy II", "Information Security Management Handbook" and others.
Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security
management (see list www.info-secure.org) . His blog http://www.securitywarrior.org is one of the most
popular in the industry.

In addition, Anton teaches classes and presents at many security conferences across the world; he recently
addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He works on
emerging security standards and serves on the advisory boards of several security start-ups.

Currently, Anton is developing his security consulting practice www.securitywarriorconsulting.com, focusing
on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin
was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a
Chief Logging Evangelist, tasked with educating the world about the importance of logging for security,
compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic
product management role. Anton earned his Ph.D. degree from Stony Brook University.

								
To top
;