1. 1 SELinux/RHEL5 Ken Rielly Dan Walsh BASE OS Engineering Red Hat Software, Inc. Company Confidential

2. 2 What is SELinux? ● Security-enhanced Linux ● Research prototype ➢ Developed by NSA ➢ Linux kernel and a number of utilities ➢ Demonstrate the value of mandatory access controls Type Enforcement Role-based Access Control Has no concept of a "root" super-user, ➢ Does not share well-known shortcomings of traditional Linux security mechanisms (such as a dependence on setuid/setgid binaries). "The best practices for computer security includes the idea of least privilege, meaning the absolute minimum amount of access is given each user, process, or program to perform their required tasks." --Rick Larabee A Comparison of SELinux and LIDS

3. 3 Discretionary Access Control (DAC) DAC is the model commonly used by UNIX systems ● Users have complete control over files they own and programs they use ● Programs run by a user have all rights that the user ● Users can allow others access to their objects at their discretion ● The level of system security is left to the discretion of the applications running on it. ● If a program running as root user is compromised then the attacker could gain root privileges, and the security of the entire system is compromised.

4. 4 Mandatory Access Control (MAC) ● Operating system security is fundamental to the security of every computing system. ● Attempts to secure computer systems based on flawed assumption ➢ Adequate security can not be provided in applications ● Secure applications require secure operating systems, ● Integration MAC significantly improves system security ➢ MAC protects information from legitimate users with limited authorization as well as from authorized users who have unwittingly executed malicious applications. ● SELinux has strong, flexible MAC architecture ● Hardened Operating System

5. 5 Policy Roles-Based Access Control Implementing a MAC model on a UNIX system very difficult ● Defining rules for every user to use every program to access every object would result in an enormous set of rules. ● Under RBAC, administrators define roles and allow certain users access to those roles. ● Example: an accountant would want read and write access to the accounts database but nothing else, and a system auditor should be able to read all of the system logs and configuration files, but never be able to write to them. By defining roles in a system, defining which objects certain roles can access, and allowing various users to assume various roles, the task of defining a mandatory access security policy is greatly simplified.

6. 6 Policy Type-Enforcement ● SELinux tags each and every process and file with a security context to which it belongs ● A security enforcement module in the kernel permits or denies all accesses to objects such as files and devices. ● Kernel process decides which subjects (processes, users) can access which objects (files, devices). ● In SELinux, this control mechanism is called Type Enforcement (TE). ● Policy file is 200,000 lines long. ● Policy requires experts to design, and it is not expected that system administrators should be changing policy.

7. 7 Integration of SELinux in RHEL Working Assumptions ● 32-bit Intel-compatible systems only ● Not in RHEL3 kernel ● Red Hat not assuming development ownership of the SELinux patches ● Red Hat's involvement is integration and productization ● Red Hat will not be adding MAC to X-Windows

8. 8 NSA SELinux Package ● NSA Provided Package based on Red Hat Linux 7.2. ● Changes not done as patches, fairly old. ● Most work needs to be redeveloped on newer modules. ● Several tools (passwd, useradd, groupadd) wrapped

9. 9 ● Packages not included in SELinux prototype ● X-Windows Login: All login programs will need to grab the initial role for the user logging in. ● Gdm, kdebase, Xfree86-xdm ● User Management: ● Redhat-config-users, shadow-utils ● Service Management ● redhat-config-services,Chkconfig ● File Managers ● Nautilus,konqueror ● kcron ● Backup Utilities: Maintain contexts when performing backup and copy ● Cpio, zip ● Sudo Additional Package Changes

10. 10 Configuration Tools ● /usr/bin/consolehelper will not work in SELinux ● Even though application(s) runs suid, the configuration files cannot be written by the current user ● User must run“newrole to change roles to one that manipulate the config files ● Desktop files need to include the user role required to run application ● Application should prompt for user's password rather than root's password ● Consolehelper will need to change to appropriate role

11. 11 Software Audit Functions fail in unexpected ways. ● If role is not changed to sysadm_r before executing su bash: /root/.bashrc: Permission denied Creation of the /root/.xauth* file fails causing X-Windows being created as root to fail ● Redhat-config-users returns unexpected error ● Normal network tools from user space ping 4.2.2.2 ping: icmp open socket: Permission denied traceroute 4.2.2.2 ping: icmp open socket: Permission denied ● copying from another machine scp root@pxe:/var/log/t.html. root@pxe's password: bash: /root/.bashrc: Permission denied scp: /var/log/t.html: Permission denied

12. 12 Software Audit Unreported failures ● The following log is from a successful login. ● Login program fails to access kerberos configuration. Failure causes program to take another code path without reporting the error to the user. ● Something bad might have happened but the user would never know. ● Errors in log file need to be researched.

13. 13 Feb 19 14:29:26 pxe login(pam_unix)[902]: session opened for user dwalsh by LOGIN(uid=0) Feb 19 14:29:26 pxe kernel: Feb 19 14:29:26 pxe kernel: avc: denied { write } for pid=902 exe=/bin/login path=/etc/krb5.conf dev=03:02 ino=228079 scontext=system_u:system_r:local_login_t tcontext=system_u:object_r:etc_t tclass=file Feb 19 14:29:26 pxe kernel: Feb 19 14:29:26 pxe kernel: avc: denied { write } for pid=902 exe=/bin/login path=/etc/krb5.conf dev=03:02 ino=228079 scontext=system_u:system_r:local_login_t tcontext=system_u:object_r:etc_t tclass=file Feb 19 14:29:47 pxe -- dwalsh[902]: LOGIN ON tty1 BY dwalsh USING dwalsh:user_r:user_t Feb 19 14:30:03 pxe kernel: Feb 19 14:30:31 pxe kernel: avc: denied { ipc_owner } for pid=1059 comm=X capability=15 scontext=dwalsh:user_r:user_xserver_t tcontext=dwalsh:user_r:user_xserver_t tclass=capability Feb 19 14:30:33 pxe kernel: avc: denied { search } for pid=1059 exe=/usr/?X11R6/bin/XFree86 path=/home/dwalsh/.gnome2 dev=03:02 ino=606170 scontext=dwalsh:user_r:user_xserver_t tcontext=dwalsh:object_r:user_home_t tclass=dir Feb 19 14:30:34 pxe kernel: avc: denied { getattr } for pid=1103 exe=/usr/bin/fam path=/tmp/.fam_socket dev=03:02 ino=212430 scontext=system_u:system_r:inetd_t tcontext=system_u:object_r:tmp_t tclass=sock_file Feb 19 14:30:34 pxe kernel: Feb 19 14:30:34 pxe kernel: avc: denied { unlink } for pid=1103 exe=/usr/bin/fam path=/tmp/.fam_socket dev=03:02 ino=212430 scontext=system_u:system_r:inetd_t tcontext=system_u:object_r:tmp_t tclass=sock_file Feb 19 14:30:37 pxe kernel: avc: denied { ipc_owner } for pid=1059 comm=X capability=15 scontext=dwalsh:user_r:user_xserver_t tcontext=dwalsh:user_r:user_xserver_t tclass=capability Feb 19 14:30:41 pxe kernel: AVC: 7 messages suppressed. Feb 19 14:30:41 pxe kernel: Feb 19 14:30:41 pxe kernel: avc: denied { ipc_owner } for pid=1059 comm=X capability=15 scontext=dwalsh:user_r:user_xserver_t tcontext=dwalsh:user_r:user_xserver_t tclass=capability

14. 14 RPM and RHN Changes RPM ● Packages need to apply the security domain to content files. ● New policy files need to be loaded into the kernel. ● Modify RPM to specify domains of files within the package. ● RPM package scripts need to be tested and modified. ● RPM might not have the correct role to start a service. RHN ● The RHN update daemon needs to be looked at since it will run at a privileged level. It will need to have the privileges to run RPM.

15. 15 X-Windows ● SELinux designed as a server only operating system. ● X-Windows has not been ported use SELinux ● NSA says anyone who has tried has been unsuccessful ● X-Windows on SELinux breaks security model ● X-Windows allows non-privileged application to grab information from privileged application. ● For instance. If I am running a browser application reading highly secure information in one window and a unprivileged stock ticker in another. The stock ticker application has the ability to read everything that X-Windows has on the screen. ● add SELinux support to X-Windows requires all interaction between windows be checked against the policy.

16. 16 System Calls ● SELinux adds additional calls to system calls (ex: accept) ● Calls return the SID relative to the operation. ● Calls currently are in a separate library (libsecure). ● Calls need to be moved into the main libraries ● All man pages need to be updated. NAME accept, accept_secure accept a connection on a socket SYNOPSIS #include int accept(int s, struct sockaddr *addr, int *addrlen); int accept_secure(int s, struct sockaddr *addr, int *addrlen, security_id_t *sid); accept_secure takes an additional result parameter, sid, that is filled in with the security identifier of the peer socket.

17. 17 Additional SELinux System Calls Modified System Calls

18. 18 Policy Management Tools ● TRESYS TCL/TK tools used to manage security profiles. ● TRESYS Policy Tools ● Apol: This tool is used to analyze policy.conf files (e.g., show all types with a given attribute, show all TE rules that involve a given type/attribute, find roles that include a given type, review defined users). ● Seuser: This is a GUI and command-line user manager application for SELinux. This tool allows one to properly add, remove, and change user accounts defined in the SELinux policy. ● SePCuT: This GUI tool allows you to customize, browse and edit components of an SELinux policy. It may be also useful for policy development purposes in allowing one to test, install and/or load the customized SELinux policy.

19. 19 Maintaining Default Policy ● Most difficult part of adopting SELinux into Red Hat Enterprise Linux. ● All RHEL services must be studied. ● Each service needs default policy ● Policy must be QA'd ● least access possible for that service. ● NSA provides a default Policy. ● Much of what ships with Red Hat not covered by policy. ● Community developing policy for some applications on adhoc basis. ● NSA agrees to help writing policy with Red Hat resource

20. 20 Maintaining Default Policy Policy Maintainer (Security Expert) ● Handle bug reports about broken policies. ● Handle shipping Errata for broken Policies. ● Study third party applications and design policies for them. ● Analyze open source policies for includes in RHEL. ● Work with NSA on Policies Global Support Services (GSS) Policy Service ● Offer a service to define policies for applications. ● Write policies for Customers' own homegrown or third party applications. Global Learning Services (GLS) ● Offer courses on how to write and modify policy. Red Hat Network (RHN ) ● Supply policy files within RPMS and via RHN. ● Deliver erratas for Policy.

21. 21 Feature Integration Plan Phase 1 Initial SELinux Integration ● I ntegrate current non-kernel SELinux patches with RHEL 3 ● Kernel changes will be made to 2.5 kernel. ● Does not address security policy, use NSA default policy ● Results of this phase will be the functional equivalent of SELinux based on RHEL3 with a 2.5 kernel.

22. 22 Feature Integration Plan Phase 2 Complete SELinux Integration: ● Complete changes in OS Packages, System Calls, and Kernel Issues. ● Policy Management Tools ● Management Tools allow users to manipulate policies and check them for accuracy. ● Final Integration of OS Features ● Documentation provided describing how to create policy. ● Major changes to the Kernel for supportability and performance. ● Fixing all bugs found in via QA ● At the end of this Phase SELinux will be ready for Beta.

23. 23 Feature Integration Plan Phase 3 First Customer Ship ● Incorporate fixes and changes discovered by beta testing ● Release as component of RHEL 4 ● Maintain Default Policy: Red Hat will provide a default security policy (A Hardened OS) ● Red Hat will provide errata and updates of security policy. ● RHN is the mechanism for providing and updating the policy