Papillon 0.5.4 – Solaris Security Module Documentation and Manual
Total Page：16
File Type：pdf, Size：1020Kb
Papillon 0.5.4 – Solaris Security Module Documentation and Manual Konrad Rieck ([email protected]) September 5, 2006 − Revision: 1.81 Copyright 2000 – 2003, 2006 Contents 1. Introduction 3 2. Papillon’s functionality 4 2.1. Features ....................................... 4 2.1.1. Restricted Proc ............................... 4 2.1.2. Pseudo Promiscuous Flag ......................... 5 2.1.3. Secure STDIO File Descriptors ...................... 5 2.1.4. Module Hiding ............................... 6 2.2. Protections ..................................... 6 2.2.1. Symbolic Link Protection ......................... 7 2.2.2. Hard Link Protection ............................ 7 2.2.3. FIFO Protection .............................. 8 2.2.4. Chroot Protection .............................. 9 2.2.5. Setuid Execution Protection ........................ 9 3. Installation and Configuration 10 3.1. Installation ..................................... 10 3.1.1. Requirements ................................ 10 3.1.2. Compilation Time Configuration ...................... 11 3.1.3. Compilation ................................ 13 3.1.4. Testing the Build .............................. 14 3.2. Runtime Configuration ............................... 16 3.2.1. Control Tool Options ............................ 16 3.2.2. Command Line Examples ......................... 17 4. Closing Words 19 4.1. Known Problems .................................. 19 4.2. Feedback ...................................... 20 4.3. Thanks ........................................ 21 A. Appendix 23 A.1. CHANGES ...................................... 23 A.2. LICENSE ...................................... 24 2 1. Introduction Papillon is a security module designed for the Solaris Operating Environment [7]. It provides security mechanisms and protections that improve the overall security of the system by adding new functionality to the kernel. The security mechanisms and protections have been inspired by the Openwall [5] and the HAP [2] Linux kernel patches and address common Unix security issues that are also present in the Solaris Operating Environment. In the current version Papillon supports Solaris (8, 9 and 10) and OpenSolaris [4] running on x86 and SPARC architectures in 32 or 64bit mode. Papillon follows the philosophy of prevention through restriction. By adding minimal restric- tions to resources, such as symbolic links or FIFOs, compromises based on common attack tech- niques can be prevented without influence on the system’s usability. Papillon is a great addition to already existing security solutions such as Solaris DTrace, the Basic Security Module (BSM) and the non-executable stack on the Solaris SPARC Edition. All features and protections of the Papillon module can be en- and disabled at compilation time or even at runtime, therefore the functionality can be optimally adapted to a specific system. Even though there have been several requests, the module is not designed to weaken the super- user’s privileges and protect against intruders that already compromised the system. Restricting these privileges requires a special design of the operating system, e.g. in Trusted Solaris [12] or OpenBSD [3], and is nearly impossible to implement using plain loadable kernel modules. The following documentation and manual is divided into two major parts. The first part intro- duces Papillon’s functionality and its impact on the system’s security in detail. The second part describes the compilation, installation and configuration of the Papillon module and its compo- nents. In order to correctly integrate the module into your system, it is essential to study both parts of this documentation, in order to learn about the provided functionality and its installation. Papillon is not one of those simple software packages, incorrect installation or misconfiguration may have an opposite effect on the security of the target system. 3 2. Papillon’s functionality For simplicity Papillon’s functionality has been divided into functional units that act either as so called features or security protections. – Features Features add completely new functionality to the kernel. They can be switched on or off either at compilation time or later at runtime using the provided control tool papctl. – Protections Protections restrict access to resources if specific conditions occur. A protection has a behaviour that can be none for doing nothing, warn for warning only or deny for warning and denying access to the specific resource. 2.1. Features Following is a description of each feature implemented in the Papillon module 0.5.4 . For each feature the following part lists a short introduction to the addressed security issue and a descrip- tion how the module fixes the problem. Additionally some implementation details are provided that are intended for developers that want to modify or extend the module’s code. As mentioned above features, loaded with the Papillon module into the Solaris kernel, can be switched on or off either at compilation time or later at runtime. 2.1.1. Restricted Proc By default users in the Solaris Operating Environment are able to monitor all active processes (e.g. by using the programs ps or top). An attacker that has local access to the system might gather useful information by watching system daemons and other users’ processes. The public information about all running processes also represents a lack of privacy, if a system hosts several users. If the Restricted Proc feature is enabled, users are only able to view own processes which are run- ning under their user ID (UID). It is impossible for an attacker to monitor other users’ processes because Papillon directly restricts access to the /proc file system which is the global source for all information about running processes. 4 In order to allow system’s maintenance the super-user is able to view all processes. A special group can be added whose members are also able to view running processes when the Restricted Proc feature is enabled. Papillon extends the access() function of the procfs vnode operations provided by prvnodeops in order to implement the above feature. The Solaris OE does set the correct permissions on the files inside the /proc file system but does not implement an access() function in the procfs kernel module. Papillon simply adds this missing access() function. The Restricted Proc fea- ture has been inspired by the Openwall [5] Linux kernel patch and is also briefly discussed in the presentation [9] by Konrad Rieck and Job de Haas. 2.1.2. Pseudo Promiscuous Flag The Solaris Operating Environment 9 and previous Solaris versions don’t provide a promiscuous mode flag for network adapters that is exported to the user. An administrator is not able to mon- itor a network device for an attacker sniffing on the device. Papillon is able to log all attempts to turn a network device into promiscuous mode that are done using the DLPI interface. Most sniffers, e.g. snoop or libpcap-based sniffers as tcpdump, use that interface to communicate with network adapters. Requests that are performed using a different approach are not detected. Below is an example syslog entry created by the Papillon module indicating that a network device has been put into promiscuous mode Mar 26 20:16:37 fluffy papillon: WARNING: Promiscuous mode enabled on interface hme (cmd: tcpdump, pid: 6179, uid: 0, gid: 1). Papillon intercepts the putmsg() system call and filters messages that match DLPI promiscuous on requests. If such a message is detected a warning is send to the syslog. The module is not able to detect a network interface changing back from promiscuous mode to normal operation mode. 2.1.3. Secure STDIO File Descriptors By default Unix uses the file descriptors 0, 1 and 2 for special purposes – the standard IO (STDIO) which includes in- and output of programs to and from the console. Typically these in- and outputs can be combined and filtered using so called pipes. Below is a list of the three STDIO file descriptors. STDIN File descriptor 0 is used for the standard input stream. STDOUT File descriptor 1 is used for the standard output stream. STDERR File descriptor 2 is used for the standard error stream. If an attacker closes one of these file descriptors and executes an program with the setuid or set- gid bit set, a file descriptor inside the program might be assigned to one of the closed STDIO file 5 descriptors. In this case information written to STDIN, STDOUT or STDERR might be written to a file. By using this technique an attacker is able to destroy or modify system files. Papillon intercepts the execution of all binaries that have the setuid or setgid bit set. If one of the STDIO file descriptors is closed before executing such a program, Papillon fake opens the descriptor during the execution of the program. Therefore no program with the setuid or setgid bit set is able to accidentally assign a file to the STDIO file descriptors. Below is an example entry from the syslog that illustrates the fake opening of STDIO file descriptors. Mar 26 20:25:47 fluffy papillon: WARNING: Fake opening STDERR before executing /tmp/a (cmd: sh -c /tmp/a, pid: 6472, uid: 101, gid: 101). Papillon intercepts the execve() system call and watches vnodes with the setuid or setgid bit set. If one of the STDIO file descriptors is closed before execution, it is faked opened using the kernel allocation routine ualloc() and unallocated after execution. The problem of closed STDIO file descriptors is discussed inside the Openwall [5] Linux kernel patch. 2.1.4. Module Hiding In most cases it is not necessary to hide a security module. But if an administrator wants to monitor an existing attacker, it might be necessary to make the attacker believe that the system is not protected by any security software. Papillon is able to remove itself from the list of loaded kernel modules and can operate invisible. It also denies any access to the module’s files and hides them from directory listings, including the module itself, init-scripts and the control program. The super-user is able to view and access all of these files. The list of files that are hidden can be extended at compilation time, but not at runtime, so that an administrator can add other files that are not visible to the system’s users.