|
This article will cover the issues of Linux hardening, with a specific focus on kernel hardening and its use on production systems. Several kernel-hardening approaches and their usability will be 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, and that can be automated and applied to systems that have been in operation for a long time. It would be ideal to be able to make securing systems understandable by regular system administrators who don’t have 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 hardening the system. It is beyond the scope of this article to discuss system hardening; however, there are a number of system hardening resources available, 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)
There are also utilities available, such as Bastille linux. The latter automate the hardening process with detailed explanations on each step. Hardened Linux distributions such as EnGarde Linux and Immunix are also available. Typical steps that are taken during the system hardening include:
- Minimizing installed software
- Patching the system
- Securing filesystem permissions and S*ID binaries
- Improving login and user security
- Setting some physical and boot security controls
- Securing the daemons via network access controls
- Increasing logging and audit information
- Configuring vendor supplied security software (IDS, host firewall)
It is curious to note that hardening is not just a matter of fixing bad defaults the vendors throw at users. It is believed that vendors ship systems with mostly open default setting based on customer feedback. Thus hardening should be viewed not as "fighting the evil vendor", but rather as optimizing the system based on local business and security needs.
Hardening is also a great example of defense in depth. Such a 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 a 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 prohibited using ‘access control’ 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. Kernel hardening can be 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? Current Linux kernel security can be tightened a bit without adding any new features or patches. One can compile the kernel with no module support (in this case, most kernel rootkits cannot function) and some security-related kernel options can be turned on.
Openwall
A more advanced approach to kernel patching is to remove some potentially dangerous behavior without adding any new security features. The most well-known kernel security patch of this kind is the Openwall Project, which 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. The Openwall patch provides the following features:
- Non-executable user stack area: makes running buffer overflow exploits more difficult. Heap overflows will work under this protection;
- 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;
- Restricted writes into unowned FIFOs (named pipes): makes certain data spoofing attacks harder by allowing users to write data to pipes they do not own;
- Secure /proc: prevents users from looking at the information for processes they do not own;
- Special handling of default files descriptors for SUID binaries: it helps prevent some attacks against the file handles by SUID programs; and,
- Several security-related improvements related to process memory space handling such as deallocating shared memory segments not associated with any process.
As stated previously, the patch breaks some functionality in applications such as databases. It should be deployed with great care after testing on similar machines. See the Openwall Project FAQ to learn of many issues that can arise. Openwall will protect the system from many stack overflow exploits, but not from heap overflows and stack overflows written to bypass the patch. To install the patch, download the kernel (the 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 the kernel as usual. If using the GUI kernel config, a new menu for security configuration will appear:
Now try some buffer overflows or the included stack test program.
Several features of Openwall (overflow and /tmp symlink protection, no while) make a nice addition to any system connected to the network and should be implemented if increased security is desired.
Another product that can be used in kernel hardening product is LIDS (Linux Intrustion Detection System). LIDS introduces much more changes to Linux kernel and imposes some restrictions upon use and administration practices. LIDS is covered in detail in a series of SecurityFocus articles by Brian Hatch, which can be found at: http://www.securityfocus.com/infocus/1496.
LIDS is a somewhat misleading name since the program’s 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 capabilities (such as for raw device access or password change). Its protection expands into the kernel space as well and it will stop malicious kernel modules from loading. In addition, it has built-in kernel port scan detector.
The LIDS philosophy 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 append-only. There is also a set of global capabilities.
To configure LIDS, one should download a package from http://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:
 
Before rebooting one should configure LIDS rules using the "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 programs will probably not run with LIDS configured. To achieve maximum security, one has to figure out the minimum necessary permissions for each running program (those that access the network can be especially tricky) and then configure LIDS to only allow those programs. Observing the system logs for LIDS reports about violations and then allowing the actions can do this, although it does require a lot of 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 with no LIDS protection at all. LIDS protection feature set is very rich.
LIDS is an excellent security tool if one is willing to invest time in learning its principles, functionality, and interface, and, after all that, configuring the system programs to run under 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 Secure Linux distribution is built around LIDS.
Other Options
There are several other kernel patches aimed at increasing security, namely:
These options all implement some model of Mandatory Controls. Other tools modify kernel to log all set*id() system calls to augment the audit information. Grsecurity introduces a large set of kernel 2.4 security patches, that incorporate the Openwall patch, increased audit logging and many others. Separate defensive kernel modules (such as StJude) were written to protect Linux system from exploits due to buggy software by restricting what running processes can do. There are simply too many tools related to kernel hardening to list in an article of this scope.
Some Problems with Kernel Hardening
First, what does kernel hardening aim to achieve? Greater security. But does having all the MAC features, capabilities, restricted this and that give one a system that is necessarily less likely to fall victim to abuse? No, not unless the system is configured properly. Thus, having security-enhanced kernel might provide a false sense of security (similar to companies who simply install firewalls and feel that they are adequately protected). Which 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 in place is anything but.
Even if the seemingly insurmountable tasks of proper setup and maintenance are properly completed, the system can still be compromised. It is well known that security software contains bugs. Recently TESO announced a serious bug was discovered in LIDS that might lead to a system breach. Additionally, 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 simply a game 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 complexity, it should only be deployed in cases where a clear need for increased security and expertise for properly installing and, more importantly, 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.
Anton Chuvakin, Ph.D. is a Senior Security Analyst with netForensics, a security information management company that provides real-time forensics software solutions.
|