SELINUX SECURITYENHANCED LINUX By Arpit Pandey FACT ABOUT
SELINUX (SECURITY-ENHANCED LINUX) By: Arpit Pandey
FACT ABOUT UNIX SYSTEM 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. ”
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 Linux Access Control involves : Kernel Controlling Resources (file, directory, socket etc. ) Process (running program) access to
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
DISCRETIONARY ACCESS CONTROL • 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 identitybased access control (IBAC).
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? ? q A kernel level MAC (Mandatory Access Control) implementation for Linux. q Originally commissioned and built by/for the NSA. q Make it possible to configure the system to meet a wide range of security requirements. q Limit what the process is allowed to do with the object. q 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 SELinux policy is the set of rules which guides through the SELinux Engine 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 who prefer the command line may use the 'sestatus' command to view the current SELinux status
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). User Role Type Level
SELinux Enabled SELinux Mode Selection SELINUX WORKING Enforcing Mode SELinux Policy (Strict/Targeted) Permissive Mode Access Decision? Check Security Context of subject and object Access Not Granted No Authenticate Security Yes Access Granted
Subject (Process) SELINUX ARCHITECTURE Access OK? Security Server (SS) Access Vector Cache (AVC) Yes/No Policy Yes/No Linux-Kernel Access? Yes/No Yes Object (file, socket, . . ) No SELinux access denies will be logged in: /var/log/audit. log
SELINUX DESIGN User Level Process User space Linux Security Model (LSM) is to mediate access to internal kernel objects • By placing hooks in kernel code just before the access • open system call look up inode error checks LSM Policy Engine DAC checks Examine context. LSM module provides the functions to be called by these hooks Kernel space OK? LSM hook Yes or No access inode Does request pass policy? Grant or Deny.
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. DOMAIN TRANSITION type_transition source-type(s) target-type(s) : class(es) new-type ;
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 Team Leader Director 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: s 0 – Range: s 0 -s 15: c 0. c 1023 • Sensitivity and category/compartment list • Usually translated – S 15: c 0. c 1023 -> “System High” – S 0 -> “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 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.
DAC vs MAC Discretionary Access Control Mandatory Access Control • • • § • • • Familiar, easy to understand model used by most operating systems users have control (discretion) over their files and 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 § § § § 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 Policy Kernel Enforcement Discretionary Access Control Once a security exploit gains access to privileged system components the entire system is compromised Mandatory Access Control Kernel policy defines application rights, firewalling applications from compromising the entire system 31
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 • • • http: //www. centos. org/docs/5/html/Deployment_Guide-en-US/sec-mlsov. html http: //developeriq. in/articles/2011/jul/18/selinux-security-enhanced-linux/ http: //hackinglinux. blogspot. com/2007/05/selinux-tutorial. html http: //wiki. centos. org/How. Tos/SELinux http: //www. slideshare. net/koolhead 17/atuljha-selinux http: //docs. fedoraproject. org/en. US/Fedora/13/html/Managing_Confined_Services/index. html http: //selinuxproject. org http: //en. wikipedia. org/wiki/Security-Enhanced_Linux http: //fedoraproject. org/wiki/SELinux http: //code. google. com/p/sepgsql/wiki/Apache_SELinux_plus http: //oss. tresys. com/projects/slide/chrome/site/help/com. tresys. slide. do c. user/webdocs. htm http: //flylib. com/books/en/2. 803. 1. 24/1/
- Slides: 36