Red Hat Linux Networking , System Administration (P30) ppsx

41_599496 pt05.qxd 8/30/05 7:13 PM Page 834 835 This chapter is a primer on Security-Enhanced Linux, or SELinux. SELinux is a new and much stronger security model for Fedora Core- and RHEL-based systems. Although it is most appropriate for use in situations that demand strict security, SELinux can also be used in server and desktop environments. SELinux is also significantly different from traditional Linux and UNIX secu- rity models, so it takes some time to change certain assumptions about system access and to unlearn certain practices (mostly finger habits) that are incom- patible with the security model that SELinux enforces. The material in this chapter is introductory and intended to familiarize you with SELinux and the mandatory access control model on which it is built, and to show you how you can get started using SELinux features. Understanding SELinux SELinux is a set of patches to the Linux kernel and key supporting utilities that implement mandatory access control and role-based access control. Created by the United States National Security Agency (NSA) as part of ongoing research into information security, mandatory access control and role-based access con- trol make it possible to implement strict information separation at the kernel level. The purpose is to maintain and enforce confidentiality and data integrity Exploring SELinux Security IN THIS CHAPTER ■■ Understanding SELinux ■■ Using SELinux ■■ Finding More Information about SELinux CHAPTER 33 42_599496 ch33.qxd 8/30/05 7:31 PM Page 835 on multiuser systems by giving the kernel the ability to enforce access control based on policy. One common scenario in which mandatory access control and role-based access control can be used occurs when you need to restrict root’s omnipotence. Policy-based access control, enforced in the kernel, makes it pos- sible to prevent root from accessing certain files, for example, while still main- taining full ability to administer the system. Another common use for access control is to limit the damage done by flawed or malicious code. A typical exploit method is to create a buffer overflow in an application running with root privileges that results in executing arbitrary code, such as command shell. While SELinux cannot prevent the buffer overflow, it can limit the damage caused by unauthorized access to a root shell. Even though SELinux was created by the NSA, which is responsible for the United States’ signal intelligence activities, it is freely available under the same terms and conditions as Linux itself, the General Public License. Initially released on 22 December 2000 for the 2.2.12 kernel, SELinux has constantly been improved and kept up to date with developments in the mainstream ker- nel. Surprisingly, SELinux has been accepted by the Linux community and incorporated into most of the major Linux distributions, including Fedora Core, RHEL, SUSE Linux (now known as Novell Enterprise Desktop), Debian, and a version of Gentoo Linux known as Hardened Gentoo). NOTE SELinux patches were not present in RHEL 3, only RHEL 4. Mandatory and Role-Based Access Control The standard Linux security model is referred to as discretionary access con- trol, or DAC, because file access and other resource-related decisions are made based on user identity and a relatively small set of object permissions (read, write, and execute for a given user, a given group or groups, and/or other users). In a DAC-based security model, therefore, programs executed by a spe- cific user have extremely wide discretion to do (practically) anything to that user’s resources. Moreover, the root user and programs running as the root user have almost total discretion over all resources owned by all users. The implication for flawed or malicious software is clear: effectively complete con- trol over files and other resources it controls via the user identity associated with the program. In a less hostile security environment, DAC provides an acceptable level of security against unintentional or accidental damage and a reasonably robust defense against casual attempts to exploit it. DAC also relies on the good will and common sense of users to exercise their powers respon- sibly, assuming, for example, that a user won’t make the company payroll files readable by all users. 836 Chapter 33 42_599496 ch33.qxd 8/30/05 7:31 PM Page 836 Mandatory access control, or MAC, makes no assumptions about users’ responsibilities but does assume a hostile security environment. MAC gives security and system administrators full control over all of the resources on a system and, if properly implemented, prevents users from making risky secu- rity-related decisions. MAC works by defining a policy and then enforcing that policy on objects on the system. To take a simple example, one policy might be, “No file can be made world-readable.” To enforce this policy, users would be prevented from setting the world read bit even on files they own and programmatic attempts (using the chown system call, for example) to make world-readable files would also be denied. Even the root user would be sub- ject to this restriction. Policy enforcement happens at the kernel level and is dependent not on the user’s identity alone but on any security-related infor- mation deemed relevant. SELinux’s MAC implementation makes it possible to create fine-grained permissions for both subjects and objects. Subjects include users, programs, processes, and threads, that is, for any entity or actor. Objects refer to files and devices, or more generally, anything to which you can do something or on which you can act. Role-based access control (RBAC) is a specific type of MAC. RBAC works by grouping subjects into abstract roles. Broadly understood, a role consists of a discrete set of actions that a subject having that role is permitted to perform. The policy enforcement occurs when a role is cross-referenced against a list or table of objects on which the role can act. This cross-referencing is known as type enforcement because policy enforcement depends on the type of process (or subject) that seeks to perform some action and the type of object on which the action would be performed. Each process type, known as a domain, has a carefully defined set of objects on which it can act and an equally carefully defined set of actions that it can take. Admittedly complicated, type enforce- ment allows for fine-grained control over the users, programs, and processes on a Fedora Core or RHEL system. Exploring SELinux Security 837 WHY DID THE NSA CHOOSE LINUX? Because they can. Seriously, the NSA moved their information security research to Linux for (at least) five reasons: 1. Previous research had been conducted on niche or research operating sys- tems that didn’t reflect real-world usage. 2. They weren’t seeing the results they wanted. 3. The National Security Council was interested in Linux. 4. The NSA was interested in mutual technology transfer opportunities. 5. Linux was perceived to be the best alternative. 42_599496 ch33.qxd 8/30/05 7:31 PM Page 837 SELinux Policies Traditional MAC implementations have suffered from a key shortcoming that limited its popularity and usability: inflexibility. That is, traditional MAC implementations have been able to enforce only a single access policy. SELinux introduced the notion of multiple MAC policies and allowed administrators to define their own policies. The original SELinux policy suffered from a similar shortcoming and the resulting NSA policy was too strict. SELinux’s develop- ers eventually created two policies: the strict policy (contained in the Fedora Core and RHEL package selinux-policy-strict) that was consistent with the original and restrictive NSA guidelines, and the targeted policy (con- tained in the Fedora Core and RHEL package selinux-policy-targeted). The key difference between the strict and the targeted policy is that the tar- geted policy focuses on restricting and securing a carefully defined set of dae- mons whose compromise or failure would result in significant integrity, stability, or security compromise. The balance of the policy allows normal usage under traditional Linux security, that is, as if SELinux is not enabled. For Fedora Core 4, the targeted policy covers 80 daemons, which is too long a list to include here, so please refer to the Fedora Core or RHEL release notes for a complete list of the daemons included in the targeted policy. Using SELinux By default, SELinux as configured on Fedora Core and RHEL systems is uses the targeted policy and is enabled by default when the system boots. If you disabled SELinux during installation, you can reenable it using the Security Level Con- figuration tool. To do so, type system-config-securitylevel in a terminal window or other command prompt or select Red Hat ➪ System Settings ➪ Security Level. Figure 33-1 shows the Security Level Configuration dialog box. To enable SELinux, click the SELinux tab. See Figure 33-2. Check the Enabled (Modification Requires Reboot) check box. If the Policy Type isn’t targeted, use the drop-down box to select the targeted policy. Click the Relabel on next reboot to relabel files controlled by SELinux appropriately. Click OK to make your change take effect. Finally, reboot. CAUTION Relabeling the file system can take a very long time. Changing the SELinux policy on a running system is one of the few situa- tions in which you need to restart a running Linux system. Changing the SELinux policy requires a reboot because restarting the system under a new policy allows all system processes to be started in the proper context and reveals any problems in the policy change. 838 Chapter 33 42_599496 ch33.qxd 8/30/05 7:31 PM Page 838 Figure 33-1 The Security Level Configuration tool. Figure 33-2 The SELinux tab. Exploring SELinux Security 839 42_599496 ch33.qxd 8/30/05 7:31 PM Page 839 After rebooting, use the sestatus command to ensure that your changes take effect: # sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 18 Policy from config file:targeted Policy booleans: allow_ypbind active dhcpd_disable_trans inactive httpd_disable_trans inactive httpd_enable_cgi active httpd_enable_homedirs active httpd_ssi_exec active httpd_tty_comm inactive httpd_unified active mysqld_disable_trans inactive named_disable_trans inactive named_write_master_zonesinactive nscd_disable_trans inactive ntpd_disable_trans inactive portmap_disable_trans inactive postgresql_disable_transinactive snmpd_disable_trans inactive squid_disable_trans inactive syslogd_disable_trans inactive use_nfs_home_dirs inactive use_samba_home_dirs inactive use_syslogng inactive winbind_disable_trans inactive ypbind_disable_trans inactive The first few half dozen lines of output indicate the general status of SELinux. The output you see should be identical, with the exception of the Policy version line, which might be different on your system. The output under the Policy booleans heading shows the daemons and domains (types) for which SELinux policy is enabled. Type enforcement is enabled on policies labeled active and disabled on policies labeled inactive. As you can see in the output in the previous listing, the targeted policy is quite limited in what it protects. Check the system log file, /var/log/messages, for messages that read avc: denied (that’s two spaces between avc: and denied). Such messages indicate potential problems that might interfere with smooth system usage: 840 Chapter 33 42_599496 ch33.qxd 8/30/05 7:31 PM Page 840 # grep ‘avc: denied’ /var/log/messages May 16 22:46:59 luther kernel: audit(1116298019.278:0): avc: denied { read } for pid=3993 exe=/sbin/portmap name=libnsl.so.1 dev=hda3 ino=111865608 scontext= user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=lnk_file May 16 22:46:59 luther kernel: audit(1116298019.285:0): avc: denied { read } for pid=3993 exe=/sbin/portmap name=libnsl-2.3.5.so dev=hda3 ino=109095436 scont ext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=file May 16 22:46:59 luther kernel: audit(1116298019.314:0): avc: denied { getattr } for pid=3993 exe=/sbin/portmap path=/lib/libnsl-2.3.5.so dev=hda3 ino=1090954 36 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass= file May 16 22:46:59 luther kernel: audit(1116298019.323:0): avc: denied { execute } for pid=3993 path=/lib/libnsl-2.3.5.so dev=hda3 ino=109095436 scontext=user_u :system_r:portmap_t tcontext=system_u:object_r:file_t tclass=file May 16 22:47:09 luther kernel: audit(1116298029.443:0): avc: denied { read } for pid=4172 exe=/usr/sbin/ntpdate name=libcap.so.1.10 dev=hda3 ino=109636543 scontext=user_u:system_r:ntpd_t tcontext=system_u:object_r:file_t tclass=file May 16 22:47:09 luther kernel: audit(1116298029.482:0): avc: denied { getattr } for pid=4172 exe=/usr/sbin/ntpdate path=/lib/libcap.so.1.10 dev=hda3 ino=1096 36543 scontext=user_u:system_r:ntpd_t tcontext=system_u:object_r:file_t tclass= file May 16 22:47:09 luther kernel: audit(1116298029.492:0): avc: denied { execute } for pid=4172 path=/lib/libcap.so.1.10 dev=hda3 ino=109636543 scontext= user_u:system_r:ntpd_t tcontext=system_u:object_r:file_t tclass=file May 16 22:47:09 luther kernel: audit(1116298029.503:0): avc: denied { read } for pid=4172 exe=/usr/sbin/ntpdate name=libc.so.6 dev=hda3 ino=51207831 scontext =user_u:system_r:ntpd_t tcontext=system_u:object_r:file_t tclass=lnk_file May 16 22:47:09 luther kernel: audit(1116298029.515:0): avc: denied { write } for pid=4172 exe=/usr/sbin/ntpdate name=log dev=tmpfs ino=8273 scontext=user_u: system_r:ntpd_t tcontext=user_u:object_r:device_t tclass=sock_file May 16 22:47:09 luther kernel: audit(1116298029.527:0): avc: denied { sendto } for pid=4172 exe=/usr/sbin/ntpdate path=/dev/log scontext=user_u:system_r:ntpd _t tcontext=user_u:system_r:unconfined_t tclass=unix_dgram_socket Messages that read avc: denied mean that the SELinux policy in effect is not allowing the named executable, such as /usr/sbin/ntpdate or /sbin/portmap, to take some action. The denied action appears in braces. For example, consider the following avc: denied message: May 16 22:47:09 luther kernel: audit(1116298029.527:0): avc: denied { sendto } for pid=4172 exe=/usr/sbin/ntpdate path=/dev/log scontext=user_u:system_r:ntpd _t tcontext=user_u:system_r:unconfined_t tclass=unix_dgram_socket In this message, the /usr/sbin/ntpdate program (exe=/usr/sbin/ ntpdate) is attempting to use the sendto system call ({ sendto }) to write to the device-special file /dev/log (path=/dev/log), but SELinux is deny- ing permission to do so. The specific ntpdate process in question is process 4172 (pid=4172). Use the system for a while, attempting especially to exercise the daemon executables (shown in boldface in the listing). If you discover a feature on Exploring SELinux Security 841 42_599496 ch33.qxd 8/30/05 7:31 PM Page 841 which you rely is not working properly, refer to the section titled “Modifying the Targeted Policy” to learn how to disable policy enforcement. After you have satisfied yourself that everything is working correctly, start the Security Level Configuration tool again, and click the Enforcing check box to start enforcing the new security level. (See Figure 33-3.) Alternatively, you can use the command setenforce 1 or setenforce Enforcing at a command prompt: # setenforce 1 This command enables SELinux policy enforcement. You can use the getenforce command to see the current enforcement status: # getenforce Enforcing If you change your mind, use the setenforce command with an argument of 0 or Permissive to disable policy enforcement: # setenforce Permissive # getenforce Permissive Although not strictly required, it might be wise to reboot the system again. Enabling SELinux Manually To enable SELinux manually, use the following steps: 1. Edit /etc/selinux/config and change the policy type to read as follows: SELINUXTYPE=targeted 2. While editing /etc/selinux/config, make certain that the SELINUX variable is set to permissive, that is: SELINUX=permissive This line starts SELinux with the correct policy but still enables you to log in if there is an unanticipated problem. 3. Execute the following command to force the initialization scripts to relabel the system when it reboots: # touch /.autorelabel Relabeling the system refers to setting certain extended file system attributes that SELinux uses to enforce policy. These extended file attributes are an important part of SELinux’s protection (and a signifi- cant source of trouble if the attributes are incorrectly set). 842 Chapter 33 42_599496 ch33.qxd 8/30/05 7:31 PM Page 842 Figure 33-3 Enabling enforcement of the SELinux targeted security policy. 4. Verify that the changes took effect with the sestatus command: # sestatus -v 5. While the system is still running in permissive mode, check /var/log/ messages for avc: denied messages to identify possible problems that might interfere with smooth system usage under the new policy. 6. When you are satisfied that the system runs in a stable manner under the new policy, enable enforcing by changing the SELINUX line in /etc/selinux/config to SELINUX=enforcing. You can either reboot or execute setenforce 1 to turn enforcing on in real time. Modifying the Targeted Policy To modify the targeted SELinux policy, use the Security Level Configuration tool. One reason to modify SELinux policy is to eliminate the avc: denied messages described earlier. These messages indicate that programs are violating (rather, attempting to violate) some aspect of the targeted policy. For example, the following code shows that the ntpdate program is triggering policy violations: # grep ‘avc: denied’ /var/log/messages | grep ntpdate May 16 22:47:09 luther kernel: audit(1116298029.443:0): avc: denied { read } for pid=4172 exe=/usr/sbin/ntpdate name=libcap.so.1.10 dev=hda3 ino=109636543 scontext=user_u:system_r:ntpd_t tcontext=system_u:object_r:file_t tclass=file May 16 22:47:09 luther kernel: audit(1116298029.482:0): avc: denied { getattr } for pid=4172 exe=/usr/sbin/ntpdate path=/lib/libcap.so.1.10 dev=hda3 ino=1096 Exploring SELinux Security 843 42_599496 ch33.qxd 8/30/05 7:31 PM Page 843 [...]... be used as the primary source of system configuration files used by the system and the Name Service Switch, such as /etc/aliases, /etc/group, /etc/hosts, /etc/shadow, and so on The pam_ldap package provides Linux Pluggable Authentication Modules that support authentication, password changes, Netscape’s SSL, NIS’s ypldapd, and so on ■■ openldap-devel — Headers, libraries, and associated documentation... SELinux This chapter has only scratched the surface of SELinux For additional information about the SELinux extensions, the following sources of information will prove useful: ■ ■ NSA Resources ■ ■ ■ ■ ■ ■ NSA SELinux Information — nsa.gov/selinux NSA SELinux FAQ — nsa.gov/selinux/info/faq.cfm Fedora Project and Red Hat Resources ■ ■ The Fedora Core SELinux FAQ — http://fedora.redhat.com /docs/selinux-faq... describes a specific attribute, defining its name, the syntax for that object, and how attributes of that type are compared Similarly, each objectclass definition describes a single class of entries in an LDAP hierarchy, the context in which they appear in that hierarchy, and any mandatory components of that object Listing 34-1 shows an excerpt from the LDAP core schema, defined in the file /etc/openldap/schema/core.schema... /docs/selinux-faq ■ ■ Running Apache on SELinux — http://fedora.redhat.com /docs/selinux-apache-fc3 ■ ■ Fedora Core SELinux Mailing List — https://listman.redhat com/mailman/listinfo/fedora-selinux-list 845 846 Chapter 33 ■■ Community Resources ■■ SELinux community page — http://selinux.sourceforge.net ■■ UnOfficial FAQ — crypt.gen.nz/selinux/faq.html ■■ Writing SE Linux policy HOWTO — https://sourceforge.net... entries contains mysterious strings of decimal numbers separated by periods, which are referred to as dotted decimal values These dotted decimal entries, such as those in the attributetype, SYNTAX, and objectclass definitions, are Object Identifiers (OIDs) that refer to predefined X.500 protocol elements, object types, attribute types, and attribute values These are present in order to maintain compatibility... for the Linux less utility would be /usr/bin/less, its full pathname However, its relative distinguished name within the context of the /usr/bin directory is less, which is enough to uniquely identify it in that context The set of entries that make up a specific LDAP hierarchy are defined in a schema for that LDAP directory A schema is a text file that defines the attributes, types, and values that can... For example, if you are running an IRC server, you have to allow TCP and UDP access to port 666 7, so you would enter 6667:tcp 6667:udp in the Other ports text box (See Figure 34-3.) T I P To find out what ports and protocols a given network service uses, you can look at the /etc/services configuration file For example, if you want to know what ports and protocols the IRC daemon, ircd, requires, the following... part of the openldap-servers package, and should already be installed on your LDAP server T I P If you have multiple password, shadow, and group files on different systems that you want to merge into a single LDAP repository, you can copy them all to your LDAP server system, concatenate them, and sort them to produce single files You can then edit these files so that they only have single entries for... hostname -D “cn=ldapadmin,dc=vonhagen,dc=org” \ -w password -f passwd.LDIF ldapadd -x -h hostname -D “cn=ldapadmin,dc=vonhagen,dc=org” \ -w password -f group.LDIF These commands are ordinarily entered on one line — they are split here for formatting reasons In these commands, replace hostname with the hostname of the system on which your LDAP server is running, make sure that the credentials specified... backup mechanism, or for importing that data into a separate LDAP directory server or a replica of your primary server OpenLDAP Packages for Linux The packages that provide OpenLDAP libraries, server processes, utilities, and header files on RHEL and Fedora Core systems are the following: ■ ■ openldap — Libraries and basic documentation for running OpenLDAP clients and servers on a system ■ ■ openldap-clients . the major Linux distributions, including Fedora Core, RHEL, SUSE Linux (now known as Novell Enterprise Desktop ), Debian, and a version of Gentoo Linux known as Hardened Gentoo). NOTE SELinux patches. Resources ■■ NSA SELinux Information — nsa.gov/selinux ■■ NSA SELinux FAQ — nsa.gov/selinux/info/faq.cfm ■■ Fedora Project and Red Hat Resources ■■ The Fedora Core SELinux FAQ — http://fedora.redhat.com /docs/selinux-faq ■■. http://fedora.redhat.com /docs/selinux-faq ■■ Running Apache on SELinux — http://fedora.redhat.com /docs/selinux-apache-fc3 ■■ Fedora Core SELinux Mailing List — https://listman.redhat .com/mailman/listinfo/fedora-selinux-list Exploring