Implementing SELinux as a Linux Security Module By

Implementing SELinux as a Linux Security Module By Stephen Smalley Chris Vance & Wayne Salamon Presentation by: KASHIF HASAN khasan@cs. kent. edu

Background Security-Enhanced Linux(SELinux) is a NSA (National Security Agency) backed research project. Goals: – Promote Security Research – Address OS Security – Demonstrate MAC (Mandatory Access Controls) through Type Enforcement® technology in a mainstream OS. Note: SELinux project is not intended as a complete security solution for Linux

SELinux Background 1985: LOCK system(early Type Enforcement) – Secure Ada project through Honeywell 1990: DTMach / DTOS DTMach – Mach-based prototype DTOS (Distributed Trusted Operating System) 1995: Utah Fluke / Flask( Mother of core SELinux architecture) Fluke* - University of Utah's research operating system 1999: 2. 2 Linux Kernel (patch) 2001: 2. 4 Linux Kernel (patch) 2002: LSM 2003: 2. 6 Linux Kernel (mainline) 2006: Full network labeling

Why Linux? Linux is an open source project with many developers; therefore: • Provides an opportunity for more research. • Allows application/testing in a mainstream OS. • Improves security in an existing OS. Why SELinux? • Uses the Linux Security Modules (LSM) framework to implement flexible Mandatory Access Control (MAC) in the Linux kernel. • Restricts privileges of user programs and system servers using security labels and an administratively-defined policy.

MAC versus DAC Discretionary Access Control (DAC) is the standard security model for Linux. In this model, access privileges are based on the user identity and object ownership. Mandatory Access Control (MAC) limits privileges for subjects (processes) and objects (file, socket, device, etc). Please note: SELinux does not change any existing security in the Linux environment; rather, SELinux extends the security model to include Mandatory Access Control (i. e. both MAC and DAC are enforced in the SELinux environment).

SELinux vs. Traditional Linux • SELinux enforces MAC policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs • The ability of these user programs and system daemons to cause harm when compromised(via buffer overflow for example) is reduced or eliminated. • The confinement mechanism operates independently of the traditional Linux access control mechanisms • It has no concept of a “root” super-user, and does not share the well-known shortcomings of the traditional Linux security mechanisms(such as a dependence on setuid/setgid binaries)

SELinux vs. Traditional Linux • The security of traditional Linux – Depends on the correctness of the kernel, all the privileged applications, and each of their configurations – A problem in any one of these areas may allow the compromise of the entire system • The security of SELinux – Depends on the correctness of the kernel and its security policy configuration – While problems may allow the limited compromise of individual user programs and system daemons, they do not pose a threat to the security of other user programs and system daemons or to the security of the system as a whole

SELinux Security Policies are implemented using: – Type Enforcement® (TE) (introduced in 1985 by Boebert and Kain) – Role-based access control (RBAC) – Multi-level Security

Security Model in SELinux • Type Enforcement (TE) model – Provides fine-grained control over processes and objects in the system • Role-Based Access Control (RBAC) model – Provides a higher level of abstraction to simplify user management

TE model • Traditional TE model – Binds a security attribute called a domain to each process and a type to each object – Treats all processes in the same domain identically and all objects that have the same type identically – A pair of access matrices specify how domains can access types and how domains can interact with other domains – Each user is authorized to operate in certain domains

TE model • SELinux TE model – Uses a single type attribute in the security context for both processes and objects – A domain is simply a type that can be associated with a process. – Uses the security class information provided by the Flask architecture – Security classes can distinguish objects of the same type. – Does not directly associate users with domains; uses RBAC model to provide an additional layer of abstraction between users and domains

Users & Roles • First and second component of a security context • SELinux usernames and DAC usernames are not synonymous • Semanage is used to maintain mappings of DAC to SELinux usernames. • Roles are collections of types geared towards a purpose • Roles can be used to further restrict actions on the system • SELinux usernames are granted roles in the system

Role-Based Access Control Each user gets a set of roles Each role is assigned a set of TE domains. Note: users are not identified by Linux uids; instead a user identity attribute is used in the security context.

RBAC model • Traditional RBAC model – authorizes users to act in certain roles and assigns a set of permissions to each role • SELinux RBAC model – authorizes each user for a set of roles, each role for a set of TE domains – maintains a role attribute in the security context of each process

Policies Configuration consists of: • • • Flask definitions TE and RBAC declarations and rules User declarations Constraint definitions Security context specifications.

Limitations Performance Overhead – approximately 7%. Complexity – requires in-depth knowledge of the operating system, the security policies, and the operating environment. Maintenance – policy fine-tuning, changes required for changes to the system.

Benefit of SELinux • The SELinux’s new features are designed to – Enforce the separation of information based on confidentiality and integrity requirements – Prevent processes from • • reading data and programs, tampering with data and programs, executing untrustworthy programs, or interfering with other processes in violation of the system security policy

MLS • MLS portion of Security Context is composed of 4 parts – Low/High – Sensitivity/Category • Includes syntax to define dominance of security levels • Subjects with range of levels considered trusted subjects • Implements a variation of Bell-La Padula

Linux Security Modules (LSM) • Kernel framework for security modules • Provides a set of hooks to implement further security checks • Usually placed after existing DAC checks and before resource access • Implications? SELinux check is not called if the DAC fails • Makes auditing difficult at times.

SELinux LSM Module Policy Management Interface User Space Kernel Space SELinux Filesystem Various Kernel Object Managers LSM Hooks Figure taken from SELinux by Example Access Vector Cache Miss Yes or No? Security Server (Policy Rules and Access Decision Logic) SELinux LSM Module

Userspace Object Managers User-Space Object Manager Access Vector Cache libselinux Allow access? Yes or No? Policy Management Interface User Space Kernel Space SELinux Filesystem Access Vector Cache Figure taken from SELinux by Example Cache Miss Yes or No? Security Server (Policy Rules and Access Decision Logic)

Policy Server User-Space Object Manager Access Vector Cache libselinux Cache Miss? User-Space Security Server Load Policy User Management Policy Yes or No? Policy Management Server Policy Server User Space Kernel Space SELinux Filesystem Access Vector Cache Figure taken from SELinux by Example Cache Miss Yes or No? Security Server (Policy Rules and Access Decision Logic) Interface

Permissions • Specific to a particular Object Class • Includes traditional Linux permissions • Extends existing permissions to be finer grained • Includes SELinux specific permissions for labeling

Type Enforcement • Several major keywords – – – – type attribute typealias allow dontauditallow neverallow

Type Enforcement attribute file_type; attribute httpdcontent; #These two statements. . . type httpd_user_content_t; typeattribute httpd_user_content_t file_type, httpdcontent; #are equivalent to this one type httpd_user_content_t, file_type, httpdcontent; #These two statements. . . type mozilla_t, domain; typealias mozilla_t alias netscape_t; #are equivalent to this one type mozilla_t alias netscape_t, domain;

RBAC • Adds 2 components to security context – user – role • Adds 3 policy language keywords – allow (different than AVC allow) – role_transition (similar to type_transition) – dominance

RBAC Example #valid security context joe: user_r: passwd_t #role user_r assigned to user joe roles { user_r }; #equivalent to this one role user_r types { user_t passwd_t }; allow staff_r sysadm_r; role_transition sysadm_r http_exec_t system_r; #super_r inherits all types from sysadm_r and secadm_r dominance { role super_r { role sysadm_r; role secadm_r; }}

Conditional Policies • Allows enabling/disabling portions of policy • Booleans define in policy • Logical operations allowed – – – && || ^ ! == != • Does not support nested conditionals • Booleans modified through special applications or SELinuxfs

Configuration for running insmod • Figure 4 shows a portion of the policy configuration that allows the administrator domain (sysadm_t) to run the insmod program to insert kernel modules. • The insmod program is labeled with the insmod_exec_t type and runs in the insmod_t domain.

Figure 4: Configuration for running insmod

Configuration for running insmod • allow sysadm_t insmod_exec_t : file x_file_perms; – allows the sysadm_t domain to run the insmod program. • allow sysadm_t insmod_t : process transition; – allows the sysadm_t domain to transition to the insmod_t domain. • allow insmod_t insmod_exec_t : process {entrypoint, execute } – allows the insmod_t domain to be entered by the insmod program and to execute code from this program.

Configuration for running insmod • allow insmod_t sysadm_t : fd inherit_fd_perms; – allows the insmod_t domain to inherit and use file descriptors from the sysadm_t domain. • allow insmod_t self : capability sys_module; – allows the insmod_t domain to use the CAP_SYS_MODULE capability. • allow insmod_t sysadm_t : process sigchild; – allows the insmod_t domain to send the SIGCHLD signal to sysadm_t when it exits.

LSM Hooks • Hooks are divided into following categories – – – Task Hooks Program Loading Hooks IPC Hooks File System Hooks Network Hooks Other Hooks

Task Hooks • Manage process security information • Control process operations – Inter-process operations (e. g. kill) – Privileged operations (e. g. setuid) – Resource management (e. g. setrlimit, nice) – Also mediates the ability to query another task’s state (e. g. getpgid, getscheduler) • Hooks have full task life-cycle coverage – create() if task can spawn children – kill() is consulted to verify that the task can signal its parent – alloc_security() for a new security field – free_security() releases the security field – etc.

Program Loading Hooks • Called at critical points during the processing of an execve operation • Security field in linux_binprm structure • Hooks are to – Initialize security information – Perform access control prior to program loading – Update security information after program has been loaded • During a execve process – alloc_security() to allocate security field – set_security() to save security information to security field – compute_creds() to calculate the task’s new credentials – free_security() to free the field

IPC Hooks • Security fields added to – Common IPC data substructure kern_ipc_perm – msg_msg structures for individual messages • Hook in ipcperms for permission check • Additional hooks in individual IPC operations for fine grained control – Message queues – Shared memory segments – Semaphores

IPC Hooks • For example – shmctl(), semctl() and msgctl() are mediated by shm_shmctl(), sem_semctl(), and msg_queue_msgctl() LSM hooks – Attempt to change a semaphore count is protected by sem_semop() – Attaching to a shared memoty segment is protected by shm_shmat()

File System Hooks • Three sets of hooks – Super block hooks – Inode hooks – File hooks • Security fields into associated structures – super_block – inode – file

File System Hooks — Super Block Hooks • Secutiry field in super_block structure • Control operations such as mounting, unmounting or obtaining file system statistics • For example – sb_statfs() hook checks permission when a task attempts to obtain a file system’s statistics – sb_mount() for mounting a file system – sb_umount() for unmounting a file system

File System Hooks — Inode Hooks • Inserted into different inode operations – – create link/unlink mkdir etc. • For example – inode_permission() is called to respect kernel DAC infrastructure – inode_symlink() to check if creation of symlink is permitted – inode_mkdir() to check for permission of directory creation

File System Hooks — File Hooks • Perform additional checking on file operations, and operations such as fnctl, ioctl and mmap • For example – file_permission() can be used to revalidate read and write permissions at each access – file_mmap() to check for permission to do mmap() – file_lock() for permission to lock a file

Network Hooks • Hooks are inserted into socket-related functions – bind, connect, listen, accept, etc. • For example, mediating socket operations – – – socket_bind() socket_connect() socket_listen() socket_sendmsg() socket_recvmsg() • unix_stream_connect() for stream connections

Other Hooks • Module hooks – Mediating kernel operations on modules – Not found in 2. 6. 16 source? • System Hooks – Used to control system operations • • Whether to allow ptrace Read/write/search operations on sysctl variables Changing system time etc.

Components • • • checkpolicy libselinux libsemanage libsepol policycoreutils

libselinux • Used by SELinux aware applications • Houses user space AVC • Contains functions to – calculate AVCs – get/set/create contexts – query policy engine

libsemanage • Used to query and configure state of a running system • Provides functions to query/modify – – – – login names users network ports/interfaces file contexts level translations roles etc.

SELinuxfs • Interface between userspace and kernel • Used by libselinux and libsemanage to communicate requests with the kernel • Provides a quick and easy interface for humans • Usually not used directly from programs

policycoreutils • SELinux Management and policy analysis tools – – – – – audit 2 allow audit 2 why load policy new role restorecon semanage semodule sestatus setbool etc. . .

Customizing the policy • What we can do – Adding users – Adding permissions – Adding programs to an existing domain – Creating a new type – Creating a new role

Distributions • • • Fedora Core 3 and later Debian Gentoo Su. Se SE-BSD SE-MACH

Installation • Where to get the copy? – Free download from http: //www. nsa. gov/selinux/ • Components of SELinux Distribution – Patches to the Linux kernel (based on kernel 2. 4. 18) – Patches to a number of standard tools and utilities, support files, and documentation

References • Implementing SELinux as a Linux Security Module • SELinux installation help • Stephen Smalley, “Configuring the SELinux Policy”, 2002 • Stephen Smalley and Timothy Fraser, “A Security Policy Configuration for the Security-Enhanced Linux”, 2001 • http: //www. nsa. gov/selinux

References National Security Agency. Security Enhanced Linux, December 8, 2004. http: //www. nsa. gov/selinux/index. cfm Thompson, Kerry. The Unofficial SELinux FAQ, June 15, 2004. http: //www. crypt. gen. nz/selinux/faq. html Wade, Karsten. Fedora Core 3 SELinux FAQ, November 9, 2004. http: //fedora. redhat. com/docs/selinux-faq-fc 3/index. html Smally, Stephen. Configuring the SELinux Policy, February 2002, revised January 2003. NAI Labs. URL: http: //www. nsa. gov/selinux/papers/policy 2 -abs. cfm Secure Computing Corporation. The Origin of Sidewinder® G 2 Firewall, December 8, 2004. http: //www. securecomputing. com/index. cfm? skey=1024

More Information • SELinux Homepage: www. nsa. gov/selinux • SELinux Mailing list: http: //www. nsa. gov/selinux/info/list. cfm? Menu. ID=4 1. 1. 1. 9 • Redhat SELinux Mailing List: http: //www. redhat. com/mailman/listinfo/fedoraselinux-list • Fedora SELinux Wiki: http: //fedoraproject. org/wiki/SELinux

Thank You…. . You can find a copy of this presentation at: http: //www. cs. kent. edu/~rothstei/summer_12/ notes/