Linux Kernel Hardening Anton Chuvakin, Ph.D. (firstname.lastname@example.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.
Pages to are hidden for
"Linux Kernel Hardening"Please download to view full document