[[Authorization#Mandatory access control|MAC]] helps organizations control information flow. Security Enhanced Linux (SELinux) offers mechanisms to support [[Role-based access control|RBAC]] and [[Bell and LaPadula model|BLP]]. It is developed by NSA and donated to Linux Open Source Community. It was then adopted by Linux Torvald’s upstream kernel tree. SELinux enhances Linux security through tighter access restrictions by implementing following access control models: 1. Domain/Type Enforcement (D/TE) 2. Multi Level Security (MLS) 3. Role Based Access Control (RBAC) #### Design goals 1. Linux uses [[Authorization#Discretionary access control|DAC]]. SELinux is orthogonal to standard Linux and adds features over DAC. 2. Decouple policy from enforcement that is done by the [[TCB - Trusted Computing Base|TCB]]. 3. Flexible/configurable/loadable. 4. Included in mainline or upstream kernel. 5. Common Criteria Certification #### Deployment status SELinux has been adopted by the following: 1. Redhat Enterprise Linux → They were the early adopters, and have SELinux included by default since RHEL4 (2004). 2. Other Linux distributions → Fedora, SuSE, Ubuntu, Debian 3. SEAndroid → Android is built on top of a Linux kernel. SELinux in enforcing mode since version 4.4. Enhanced security offering such as Samsung Knox and Tresys Mobile Fortress built on SEAndroid ## Security context #### Attributes Context is defined by a collection of attributes. These attributes can come directly from Linux (ex: `attr`) or could be specific to SELinux (`selinux attrs`). The attributes could be defined for both source & target. The attributes rules are used as follows: 1. **Access** → Can access be granted? 2. **Inheritance** → If a process creates a child, what security context can be inherited? For objects, what attributes should be inherited from a directory to its subdirectories? 3. **Transition** → How can we go from one type to another within attributes? This is like `setuid` 4. **Override** → Override policy rules ![[attachments/Screenshot 2023-06-27 at 6.13.30 PM.png]] Processes, files, directories, sockets, ports, nodes, etc., all have a string like this associated with them. It is associated with every subject and object in the system. There are four parts → `userID:role:type/domain:range` 1. There is a user ID (`staff_u`) in SELinux which is separate from Linux user ID. 2. The user can have a role (`staff_r`) 3. The role can have a type (`staff_t`). 4. To implement multi-level security like BLP we have the range. The range is split up into sensitivity level (`s0-s15`) and compartment (`c0.c1023`). ### Domain/Type Enforcement (DTE) SELinux type is also called domain for processes. Let’s assume, - source → `staff_u:staff_r:staff_t:s0-s15:c0.c1023` - object → `system_u:object_r:etc_t:s0` Type enforcement is used in access decisions to decide if the subject with `staff_t` type should have access to the object with `etc_t` type. This is defined in policy rules. Types let us implement [[Role-based access control|RBAC]]. - In RBAC we have users -> roles -> permissions, we implement this through types as users -> roles -> types. #### Access rules 1. **Access rules** are defined as, `allow source target: class operation`. For example, `allow staff_t etc_t: file { read write }` will allow `staff_t` to read and write `etc_t`. 2. **Inheritance rules** → Child processes inherit parent's type and subdirectories inherit from parent directory. 3. **Transition rules** → Transistion is similar to `setuid`, you can transfer between types when executing a file. For example, `staff_t` can transition to `mount_t` by executing a binary with type `mount_exec_t`. 4. **Override rules** → No inbuilt override rules. Each access must be explicitly granted. ### Multi Level Security (MLS) MLS assumes that attributes have inherent hierarchical properties. - Executive/Manager/Employee/Public - Top Secret/Secret/Confidential/Unclassified MLS defines information flow-based access policy rules. - Information flow direction during read, write operations - Addresses Confidentiality & Integrity security goals![[attachments/Screenshot 2023-06-27 at 6.31.10 PM.png]] In `staff_u:staff_r:staff_t:s0-s15:c0.c1023`, the MLS range is `s0-s15:c0.c1023`. They are used as constraint for Type based decisions (If DAC allows, check Type. If Type allows, check MLS range). #### MLS attribute representation Source and target both have MLS ranges. A valid security label → `s15:c2,c3,c4` Each security label contains, - hierarchical sensitivity levels → s15 > s14 > s13 > ... > s1 > s0 - effective level = lowest level - clearance level = highest level - non-hierarchical categories → c0,c1,c2,c3,c4.c1023 - c2.c10 (c2 to c10) - SELinux context contains two valid levels indicating effective and clearance levels. Two labels $L_1$ and $L_2$ in [[Bell and LaPadula model|BLP]] can have four relations: 1. $L_1 = L_2$ → Levels are equal, category sets are equal 2. $L_1$ dominates $L_2$ ($level(L_1)≥ level(L_2)$; $L_2$ category set equal or subset of L1 category set) 3. L1 is dominated by L2 ($level(L_1)≥ level(L_2)$; $L_1$ category set equal or subset of $L_2$ category set) 4. $L_1$ and $L_2$ are incomparable ($L_1$ and $L_2$ are not equal and neither dominates the other Examples: - L1 = `s5:c0.c10` L2 = `s5:c0.c10` → L1 is equal to L2 - L1 = `s5:c0.c10` L2 = `s4:c1,c3` → L1 dominates L2 - L1 = `s5:c0.c10` L2 = `s15:c0.c15` → L1 is dominated by L2 - L1 = `s5:c0.c10` L2 = `s3:c0.c15` → L1 and L2 are incomparable In BLP model, information only flows up (i.e., read-down, write-up are ok)![[attachments/Screenshot 2023-06-27 at 6.51.09 PM.png]] In **BLP+ model** in SELinux, write up is not allowed. ![[attachments/Screenshot 2023-06-27 at 6.52.24 PM.png]] ### MLS policy language Implemented as policy constraint → Type enforcement based on domain/type followed by removal of permissions based on range attributes - Level, sensitivity, category, dominance statements - sensitivity s0 - sensitivity s1 - dominance { s0, s1} - New process expressions such as l1, h1, l2, h2, defined to express low and high labels of context - New label comparison operators such as eq, dom, domby, incomp, defined to compare labels![[attachments/Screenshot 2023-06-28 at 5.27.29 PM.png]] ``` mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } { read getattr execute } (( l1 dom l2 ) or (( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or ( t1 == mlsfileread ) or ( t2 == mlstrustedobject )); ``` #### Policy Examples This is a read rule. ``` mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } { read getattr execute } (( l1 dom l2 ) or (( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or ( t1 == mlsfileread ) or ( t2 == mlstrustedobject )); ``` This is a rule for write operations. We cannot write above $h_2$ but can write above $l_1$. ``` mlsconstrain { file lnk_file fifo_file dir chr_file blk_file sock_file } { write create setattr relabelfrom append unlink link rename mounton } (( l1 eq l2 ) or (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or (( t2 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or ( t1 == mlsfilewrite ) or ( t2 == mlstrustedobject )); ``` ### Transitions and object label changes A process can change type when allowed by policy. `type_transition user_t passwd_exec_t:process passwd_t` When executing a file of type `passwd_exec_t`, `user_t` can go to `passwd_t` level for execution. This is similar to the [[Setuid and access control|setuid]], but here not all programs can update the type. Only the ones that have `passwd_t` type can update the password file. So, here the user root does not have all access. Object label transitions need to consider three labels: - Original security label - Target security label - Security label of the process performing the operation ``` mlsvalidatetrans { dir file lnk_file chr_file blk_file sock_file fifo_file } ((( l1 eq l2 ) or (( t3 == mlsfileupgrade ) and ( l1 domby l2 )) or (( t3 == mlsfiledowngrade ) and ( l1 dom l2 )) or (( t3 == mlsfiledowngrade ) and ( l1 incomp l2 ))) and (( h1 eq h2 ) or (( t3 == mlsfileupgrade ) and ( h1 domby h2 )) or (( t3 == mlsfiledowngrade ) and ( h1 dom h2 )) or (( t3 == mlsfiledowngrade ) and ( h1 incomp h2 )))); ``` ### Evaluating policies Given a set of rules or policies, will a certain request be granted or denied?