By: Arpit Pandey SELINUX (SECURITY-ENHANCED LINUX)

UNIX was born in 1969 but when it was created it was not created ever thinking about security. In a 1979 document titled On the Security of UNIX, Dennis Ritchie said: “The first fact to face is that UNIX was not developed with security, in any realistic sense, in mind; this fact alone guarantees a vast number of holes.” FACT ABOUT UNIX SYSTEM

WHY DO WE NEED SECURE SYSTEM? Protect system from crashes Protect operating system from bugs Stopping application from becoming dangerous for your own data Protect from Internet threats Protect from unauthorized access

A BRIEF HISTORY OF SELINUX Originally started by the Information Assurance Research Group of the National Security Agency (NSA), working with Secure Computing Corporation. Released to the open source development community under the GNU GPL on December 22, 2000 Merger into mainline kernel in 2003 Fedora since Core 2 (2004) RHEL since version 4 (2005) Debian since Etch (2007) Ubuntu since version 8.04 (2008)

LINUX ACCESS CONTROL INTRODUCTION Kernel Controlling Process (running program) access to Resources (file, directory, socket etc.) Linux Access Control involves :

STANDARD LINUX SECURITY Processes and files have security properties –process: user and group (real and effective) –resources: user and group + access bits read, write, and execute for user, group, other Standard access control is discretionary Includes concept of resource ownership Only two privilege levels: user and root An access control list (ACL) is maintained An ACL specifies which users or system processes are granted access to objects

If an individual user can set an access control mechanism to allow or deny access to an object, that mechanism is a discretionary access control (DAC), also called identity-based access control (IBAC). DISCRETIONARY ACCESS CONTROL

STANDARD LINUX SECURITY PROBLEMS Kernel can't distinguish applications from users Processes can escape security policy No way to enforce least privilege. Granting read access is transitive. DAC policy is vulnerable to Trojan horse attack. No restriction applied to the usage of information. The privileges for accessing objects are decided by the owner of the object

WHAT IS SELINUX??  A kernel level MAC (Mandatory Access Control) implementation for Linux.  Originally commissioned and built by/for the NSA.  Make it possible to configure the system to meet a wide range of security requirements.  Limit what the process is allowed to do with the object.  Very effective if done right.

MANDATORY ACCESS CONTROL MAC mechanisms assign a security level to all information, assign a security clearance to each user, and ensure that all users only have access to that data for which they have a clearance. Provides better security than DAC Principle: Read Down Access equal or less Clearance Write Up Access equal or higher Clearance

SELINUX MODES Enforcing The default mode which will enable and enforce the SELinux security policy on the system, denying access and logging actions Permissive In Permissive mode, SELinux is enabled but will not enforce the security policy, only warn and log actions. Permissive mode is useful for troubleshooting SELinux issues Disabled SELinux is turned off The 'setenforce' command may be used to switch between Enforcing and Permissive modes

SELINUX POLICIES Strict Policy By default everything is denied and then a policy is written that gives each element of the system only the access required to function. Targeted Policy In most of the Linux systems targeted policy is used which “targets” and confines selected system processes. -- Confined and Unconfined Process -- Confined and Unconfined Users Users who prefer the command line may use the 'sestatus' command to view the current SELinux status SELinux policy is the set of rules which guides through the SELinux Engine

SECURITY CONTEXT IN SELINUX SELinux makes access decisions by checking the security context of the subject (a process or a user) against the security context of the object (such as a file or network port) and then against the action attempted (e.g. a file read, file write).

SELINUX WORKING SELinux Enabled SELinux Mode Selection SELinux Policy (Strict/Targeted) SELinux Policy (Strict/Targeted) Enforcing Mode Permissive Mode Access Decision? Check Security Context of subject and object Authenticate Security Access Granted Access Not Granted YesNo

SELINUX ARCHITECTURE Subject (Process) Subject (Process) Access Vector Cache (AVC) Security Server (SS) Security Server (SS) Policy Object (file, socket,..) Object (file, socket,..) OK? Yes/No Access Linux-Kernel Access? Yes/No SELinux access denies will be logged in: /var/log/audit/audit.log No Yes

SELINUX DESIGN User Level Process open system call look up inode error checks DAC checks LSM hook access inode User space Kernel space Examine context. Does request pass policy? Grant or Deny. OK? Yes or No LSM Policy Engine Linux Security Model (LSM) is to mediate access to internal kernel objects  By placing hooks in kernel code just before the access  LSM module provides the functions to be called by these hooks

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

TYPE ENFORCEMENT Based on a single security property – type –applied to processes and resources –represents all security relevant information Types are assigned to processes and resources. type_transition source-type(s) target-type(s) : class(es) new-type ; DOMAIN TRANSITION

TYPE ENFORCEMENT In SElinux there are three possibilities for the outcome of decisions: allowed audit allow - allow but log that this took place audit deny - deny and log that this took place

ASSIGNING PROCESS TYPES Process types are: –(default) inherited from parent process –Set by policy (type transition rule) –Set by application (e.g. login) Examples: –Bash ( user_t) -> ls ( user_t) –init (init_t) -> httpd init script ( initrc_t) -> httpd (httpd_t) –Login ( login_t) -> bash (user_t)

ROLES An organizational job function with a clear definition of inherent responsibility and authority (permissions). Developer Director Team Leader Data Base Developer

ROLE-BASED ACCESS CONTROL A user has access to an object based on the assigned role. Roles are defined based on job functions. Permissions are defined based on job authority and responsibilities within a job function. Operations on an object are invocated based on the permissions. The object is concerned with the user’s role and not the user. Effectively, there are only two roles in the targeted policy: system_r and object_r.

The top row shows our SELinux users, the middle row lists the roles, and the bottom row lists domains. A valid security context can be constructed using one item from each row as long as the three are connected. In policy, the user definition: user full_u roles { mgr_r cashier_r }; defines one of the users and its connections to roles, while the role definition: role cashier_r types { cashier_t cashier_register_t };

MULTI LEVEL SECURITY Often hidden in targeted and strict The MLS Range contains two components, the low and high (clearance) sensitivity label, in which the high must always dominate the low. Identifies one level or range –Single level: s0 –Range: s0-s15:c0.c1023 Sensitivity and category/compartment list Usually translated –S15:c0.c1023 -> “System High” –S0 -> “System Low”

THE BELL-LA PADULA MODEL (BLP)

SELINUX AUDIT MESSAGE Errors can get created for a variety of reasons –A process running the wrong context –A mislabeled file –A bug in policy

SELINUX TOOLS sestatus: A command line tool that shows the current status of SElinux on the system. –a configuration file /etc/sestatus.con seinfo: A command line tool that allows querying of the current active policy. setenforce: A command line tool to switch between the SElinux enforcing and permissive modes. semanage A general tool that allows certain parts of the SElinux configuration and policy to be altered on the fly. semodule: A command line tool for managing policy modules.

SELINUX TOOLS CONT.… restorecon: A command line tool to "restore" the default SELinux security contexts for objects given as arguments (files, directories etc.). chcon: A command line tool in the genre of chmod, chown etc. setroubleshoot: A server and graphical frontend written in python to watch real-time AVC violations.

SELINUX TROUBLESHOOTER Sooner or later we may run into situations where SELinux denies access to something and we need to troubleshoot the issue. There are a number of fundamental reasons why SELinux may deny access to a file, process or resource: –A mislabeled file. –A process running under the wrong SELinux security context. –A bug in policy. An application requires access to a file that wasn't anticipated when the policy was written and generates an error.

31 DAC vs MAC Discretionary Access Control Familiar, easy to understand model used by most operating systems users have control (discretion) over their files and programs programs run as a user have that user's privileges root/superuser has complete control Trusted programs often run as superuser attacker's goal is to exploit program running with root privileges Superuser privileges harder to breakup Mandatory Access Control  Newer concept, than DAC hard to grasp  Not part of mainstream OS  program privileges under the control of security policy  easier to implement principle of least privilege  supplements DAC  Trusted programs privileges also under the control of security policy  Attacker is contained  Role separation Kernel Policy Enforcement Mandatory Access Control Kernel policy defines application rights, firewalling applications from compromising the entire system Kernel Discretionary Access Control Once a security exploit gains access to privileged system components the entire system is compromised

CONCLUSION SELinux is a practical implementation of Mandatory Access control. As SELinux provides a strong layer of protection which is hard to ignore that’s why it makes system more robust and safe. SELinux not only protects user from viruses, Trojan horses and other malicious software but also from the bugs in the web application. Properly defined policies can help a user, but if this is not properly defined then this may cause problem and may also crash the application. So it is really important to define policies properly.

REFERENCES mls-ov.htmlhttp:// mls-ov.html linux/ linux/ US/Fedora/13/html/Managing_Confined_Services/index.htmlhttp://docs.fedoraproject.org/en- US/Fedora/13/html/Managing_Confined_Services/index.html doc.user/webdocs.htmhttp://oss.tresys.com/projects/slide/chrome/site/help/com.tresys.slide. doc.user/webdocs.htm