SELinux (Security-Enhanced Linux)

1. SELinux(Security-Enhanced Linux) By: Arpit Pandey

2. 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.”

3. 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

4. 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)

5. Linux Access Control Introduction Linux Access Control involves :

6. 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

7. 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 identity-based access control (IBAC).

8. 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

9. 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.

10. 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

11. SELinux Modes The 'setenforce' command may be used to switch between Enforcing and Permissive modes

12. SELinux Policies SELinux policy is the set of rules which guides through the SELinux Engine Users who prefer the command line may use the 'sestatus' command to view the current SELinux status

14. 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).

15. SELinux Enabled SELinux Working SELinux Mode Selection Enforcing Mode SELinux Policy (Strict/Targeted) Permissive Mode Access Decision? Check Security Context of subject and object Authenticate Security Access Not Granted Access Granted No Yes

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

17. User Level Process open system call look up inode error checks DAC checks LSM hook access inode User space Kernel space LSM Policy Engine OK? Examine context. Does request pass policy? Grant or Deny. Yes or No SELinux Design 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

18. 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

19. 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_transitionsource-type(s)target-type(s):class(es)new-type;

20. 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

21. 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)

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

23. 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.

24. 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 };

25. 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”

26. The Bell-La Padula Model (BLP)

27. 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

28. 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.

29. 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.

30. 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. Kernel Policy Kernel Enforcement Mandatory Access Control Kernel policy defines application rights,firewalling applications from compromisingthe entire system Discretionary Access Control Once a security exploit gains access toprivileged system components the entiresystem is compromised DAC vs MAC 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 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

33. 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.

34. References • http://www.centos.org/docs/5/html/Deployment_Guide-en-US/sec-mls-ov.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/HowTos/SELinux • http://www.slideshare.net/koolhead17/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.doc.user/webdocs.htm • http://flylib.com/books/en/2.803.1.24/1/