Implementing SELinux as a Linux Security Module By Stephen Smalley Chris Vance & Wayne Salamon Presentation by: KASHIF HASAN

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

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

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

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 – typeattribute – typealias – allow – dontaudit – auditallow – 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 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 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 – audit2allow – audit2why – 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 domain – Creating a new type – Creating a new role

Distributions Fedora Core 3 and later Debian Gentoo SuSe SE-BSD SE-MACH

Installation Where to get the copy? – Free download from Components of SELinux Distribution – Patches to the Linux kernel (based on kernel ) – 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 ”,

References National Security Agency. Security Enhanced Linux, December 8, Thompson, Kerry. The Unofficial SELinux FAQ, June 15, Wade, Karsten. Fedora Core 3 SELinux FAQ, November 9, Smally, Stephen. Configuring the SELinux Policy, February 2002, revised January NAI Labs. URL: URL: Secure Computing Corporation. The Origin of Sidewinder® G2 Firewall, December 8,

More Information SELinux Homepage: SELinux Mailing list: Redhat SELinux Mailing List: selinux-list selinux-list Fedora SELinux Wiki:

Thank You….. You can find a copy of this presentation at: notes/ notes/ You can find a copy of this presentation at: notes/ notes/