Presentation by: KASHIF HASAN khasan@cs.kent

1. Implementing SELinux as a Linux Security ModuleByStephen SmalleyChris Vance & Wayne Salamon Presentation by: KASHIF HASAN khasan@cs.kent.edu

2. 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® technologyin a mainstream OS. Note: SELinux project is not intended as a complete security solution for Linux

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

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

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

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

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

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

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

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

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

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

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

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

15. Configuration consists of: Flask definitions TE and RBAC declarations and rules User declarations Constraint definitions Security context specifications. Policies

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

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

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

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

20. SELinux LSM Module Policy Management Interface User Space Kernel Space SELinux Filesystem Security Server (Policy Rules and Access Decision Logic) Access Vector Cache Various Kernel Object Managers Cache Miss Yes or No? LSM Hooks SELinux LSM Module Figure taken from SELinux by Example

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

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

23. Permissions • Specific to a particular Object Class • Includes traditional Linux permissions • Extends existing permissions to be finer grained • Includes SELinux specific permissions for labeling

24. Type Enforcement • Several major keywords • type • attribute • typeattribute • typealias • allow • dontaudit • auditallow • neverallow

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

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

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

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

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

30. Figure 4: Configuration for running insmod

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

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

33. LSM Hooks • Hooks are divided into following categories • Task Hooks • Program Loading Hooks • IPC Hooks • File System Hooks • Network Hooks • Other Hooks

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

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

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

37. 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()

38. File System Hooks • Three sets of hooks • Super block hooks • Inode hooks • File hooks • Security fields into associated structures • super_block • inode • file

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

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

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

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

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

44. Components • checkpolicy • libselinux • libsemanage • libsepol • policycoreutils

45. libselinux • Used by SELinux aware applications • Houses user space AVC • Contains functions to • calculate AVCs • get/set/create contexts • query policy engine

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

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

49. policycoreutils • SELinux Management and policy analysis tools • audit2allow • audit2why • load policy • new role • restorecon • semanage • semodule • sestatus • setbool • etc...

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