|
Access:
» Secure Linux - security kit reviewRelated categories: Security | Linux Micha³ PiotrowskiViewed: 11752 | Article date: 2006-04-11 17:11:39 Linux systems are fairly resistant to intrusion attempts. However, for certain applications requiring very high security levels, the features found in standard distributions may prove insufficient. This article examines several of the most popular ways to increase Linux system security at kernel level.
Linux systems are fairly resistant to intrusion attempts. However, for certain applications requiring very high security levels, the features found in standard distributions may prove insufficient. This article examines several of the most popular ways to increase Linux system security at kernel level.
About the authorMicha³ Piotrowski holds an M.Sc. in computer science and has many years’ experience as a network and system administrator. For over three years he was a security inspector at an institution running the root certification authority for public key infrastructure in Poland. He is currently working as an IT security expert for one of Poland’s largest financial institutions. His spare-time activities include programming and cryptography. The notions of a secure and insecure operating system are deceptive. The actual security level depends primarily on system configuration and system administrator skills, covering technological and non-technological means of protection, choice of software solution and the administrator’s knowledge and experience.
What you will learn...
What you should know...
However, even the best administrator cannot protect a system against zero-day exploits that take advantage of newly discovered vulnerabilities which are not yet publicly known. Fortunately, it is largely possible to secure a system even against these threats. The majority of Linux system intrusions result from programming error exploits. Intruders typically exploit buffer overflow vulnerabilities (both on the stack and on the heap), insecure format string processing and artificially induced race conditions. It is less common to find attacks that exploit incorrectly assigned system resource access rights or errors in network mechanism and protocol support. Additional software protection solutions for Linux systems can be divided into four categories:
Table 1 presents a summary of the solutions discussed in this article, along with the categories they fall into. Table 1. Software solutions for increasing Linux system security
Kernel-level memory protectionProcess memory protection at kernel level can be achieved using two basic mechanisms. The first is to mark a selected area of memory as write-only or execute-only, and the other way is to introduce randomisation. Memory allocated to a process within the operating environment is divided into several segments:
Process memory also contains mappings for shared library functions used by the process, such as printf(), system() etc. In its standard configuration, the Linux kernel grants memory segments dangerously high privileges. For example, processes can not only write code to the stack, but also execute it, opening the way for buffer overflow attacks. To protect the system against such vulnerabilities, additional safeguards can be used to change the default memory segment privileges, so each segment can either be executable only or writeable only, for example allowing the stack to be made non-executable. However, even a non-executable stack can still be exploited using the return to libc attack. The attack involves writing a call to a shared function to the stack - typically the system() function with a parameter like /bin/sh - resulting in control being transferred to the specified function, which then executes a system shell or performs other operations required by the attacker. For this attack to succeed, though, the attacker has to know the address of the system() function in process memory, and that’s where randomisation comes in. Randomised process memory segments and shared functions have different addresses each time the program is executed, preventing the intruder from guessing the shared function addresses and therefore from executing these functions. OpenwallThe Openwall project was created by Alexander Peslyak, a.k.a. Solar Designer, who is also the author of a password cracker called John the Ripper and the Owl Linux distribution. Openwall was initially called Secure Linux Patch. The first version appeared in January 1998 and was intended for 2.0 series kernels. The patch is still being developed, but no version for 2.6 series kernels exists as yet. In the author’s opinion, there is little point in porting Openwall to the latest Linux kernel until version 2.6.20 appears. Security featuresOpenwall offers several countermeasures, of which the most important are (see Frame Kernel-level memory protection):
Other security measures include constraints on the creation of hard links and on writing to named pipes for directories with the +t bit set (i.e. temporary directories, for example /tmp). This means that ordinary users cannot hard link to files they do not own or don’t have read/write access to, nor can they write data to FIFO files they do not own. The patch also restricts read access to system information from the /proc directory to a separate user group - all other users can only access information about their own processes. Users can also be prevented from running network services on specified IPs (only for 2.0 series kernels). The patch forces programs with the SUID or SGID bit set to use a special method of working with standard input, output and error stream descriptors (2.0 and 2.2 series kernels only) and allows unused areas of shared memory to be released. InstallationTo install Openwall:
If you use non-standard versions of the glibc library or programs from the procps or psmisc packages, you may need to update them before they work correctly with all Openwall features. The patch includes the chstk utility for indicating programs authorised to execute code on the stack by setting a special flag in the ELF file header. Whenever a new process is created, the system checks the flag value and assigns the required privileges. PaXThe PaX patch is intended for 2.2, 2.4 and 2.6 series kernels. The project was created in October 2000, but was suspended in April 2005 after a serious flaw was discovered, allowing key protection mechanisms to be bypassed. Although the flaw was corrected, the authors decided that users have lost their faith in PaX and abandoned the project. The code base is currently managed by Brad Spengler, the author of grsecurity. Security featuresPaX offers similar protection to Openwall: preventing code execution on the stack and randomising memory addresses in process space. However, the two projects differ slightly in implementation details. Memory protection in PaX extends beyond the process stack - each memory segment (see Frame Kernel-level memory protection) has separate write or execute privileges. The system administrator can also select one of two protection methods: PAGEEXEC (protection through paging) or SEGMEXEC (protection through segmentation). Randomisation support allows all process memory segments to be placed at random addresses, effectively rendering the a return to libc attack impossible. Figure 1 presents the memory structure of a typical process in a standard system and in a system protected by PaX. InstallationTo install PaX:
The chpax and paxctl utilities allow selected executables to be configured to either use or bypass the PaX mechanisms, which is very useful if you’re using non-standard applications that have problems running with memory access limitations. The two utilities use different methods to control executables. Paxctl uses a more intrusive method, modifying an ELF executable header by adding several fields. Support for this method also requires modifications to utilities from the binutils package. The other method, used by chpax, has a smaller impact on system configuration, using an ELF file’s existing reserved header field, similar to the Openwall solution. The first method provides better integration of PaX into the operating system and makes it possible to use PaX in soft mode, when all security features are disabled by default and must be enabled separately for each application.
Figure 1. Stack protection using PaX
|
 
     
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
SDJ Users: 
hakin9 StarterKit IT Practical Solutions for Newbies
Copyright C 2006 by Software Developer's Journal. All rights reserved.