Implementing SELinux as a Linux Security Module

Implementing SELinux as a Linux Security Module By Stephen Smalley Chris Vance & Wayne Salamon Presentation by: KASHIF HASAN [email protected] 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 SELinuxs 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 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 Allow access? Yes or No? libselinux 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 Cache Miss? User-Space

Security Server Load User Policy Yes or No? Policy Management Server libselinux 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) Policy Management 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 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 tasks 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 tasks 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 systems 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

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 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-fc3/index.html Smally, Stephen. Configuring the SELinux Policy, February 2002, revised January 2003. NAI Labs. URL:http:// www.nsa.gov/selinux/papers/policy2-abs.cfm Secure Computing Corporation. The Origin of Sidewinder G2 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?MenuID=4 1.1.1.9 Redhat SELinux Mailing List: http://www.redhat.com/mailman/listinfo/fedora-seli nux-list Fedora SELinux Wiki: http://fedoraproject.org/wiki/SELinux Thank You.. You can find a

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

Recently Viewed Presentations

  • The Visual System Part 2 The Retina The

    The Visual System Part 2 The Retina The

    The Visual System Part 2 The Retina The Retina Photoreceptors Rods Cones Bipolar cells Ganglion Cells axons converge at optic disk axons constitute optic nerve Horizontal cells Amacrine cells Importance of abundant membrane Visual Acuity 120,000,000 rods and 6,000,000 cones...
  • Openness in Adoption

    Openness in Adoption

    Key Principles: Openness in Adoption. Handout #11.3 Current adoption practice favors openness in adoption, in contrast to practice in the past that favored closed/confidential adoptions. Handout #11.3 provides some of the key principles on which current practice around openness in...
  • Theatre Complicité - BEXLEY GRAMMAR SCHOOL PERFORMING ARTS

    Theatre Complicité - BEXLEY GRAMMAR SCHOOL PERFORMING ARTS

    Complicite tend to use physical theatre differently to DV8 or Frantic Assembly There is less dancing, plays are physical because they use an ensemble to fill the space, freeze for long periods of time, create crowds, speed up movements, use...
  • ΣΤΑΤΙΣΤΙΚΗ - unipi.gr

    ΣΤΑΤΙΣΤΙΚΗ - unipi.gr

    ΣΤΑΤΙΣΤΙΚΗ Η επιστήμη που ασχολείται με την συλλογή δεδομένων,ανάλυση και ερμηνεία αυτών
  • Chapter 22 Chemistry of the Nonmetals - HCC Learning Web

    Chapter 22 Chemistry of the Nonmetals - HCC Learning Web

    Nonmetals form covalent oxides; most give oxyacids when dissolved in water (like SO. 2 → H 2 SO 3).These oxides that form acids in water are called . acidic anhydrides. or . acidic oxides. Ionic oxides that dissolve in water...
  • Map Mashups - Dashboard - NCSA Wiki

    Map Mashups - Dashboard - NCSA Wiki

    Add direction on flow map 14_02_Flow_Map.html. Play with pre-defined symbol path. Play with the "offset" and "repeat" properties associated with an icon. How to Connect Vertices in a Polyline. Connected line segments and defined by vertices.
  • Tabular Deep Dive

    Tabular Deep Dive

    SQL Server Data Tools. Personal Team Corporate. One file, Save to SharePoint. Optimized for Excel power user. Rapid response to business problems. Solutions live for weeks or months. Design Tools. Feels like Visual Studio. Optimized for BI Pros. Teams building...
  • High School Science Course Model Update Grades 9 through 12 ...

    High School Science Course Model Update Grades 9 through 12 ...

    The Living Earth/Biology. TBD (April/May) Chemistry of Earth Systems. TBD (April/May) Physics in the Universe. TBD (Spring/Fall) Review Available Curriculum. Teachers will meet in course/subject alike groups to determine the level of content covered in each course, then review curriculum...