Lecture 10 - Operating System Security

### Lecture 10 - Operating System Security **Terminology** **Secure system** is a system if there is no way to start from a secure state and end up in a non secure state, given system can only be said to be secure with respect to some specific policy that defines what is allowed in the system. **Security assumptions** - are specific set of assumption to the type of security and the environment in which is it to be employed, if assumptions are erroneous the system will be secure. Classic Security targets are: - Confidentiality - protecting information from unauthorised disclosure - Integrity - protecting information from unauthorised modification or destruction - Availability - is prevention of denial of service (DoS) or temporary reduction in system performance or a system crash with permanent data loss OS security is the process of ensuring integrity, confidentiality and availability of the OS, *There has long been the perception that true computers security can never be achieved in practice* System are not security due to: - Security requirements are often not considered at design time and added later on as afterthought - Major technological advances in computer raise, new security threads that require new solution rise up every day - New solutions can't be deployed easily due to legacy compatibility - Secure design doesn't imply secure implementation. - Security seems to be hurdle/annoying for users - Misconceptions of security solutions - Non-technical attacks bypass OS security by targeting users **Three core principles** - **Isolation** - separate system into isolated compartments, and make interaction between compartments via well-defined interfaces, in case of any compromise damage should be confined by compartment boundaries - **Least privilege principle** - allow the minimum number of privileges necessary to accomplish the task. Privilege is ability to access or modify a resource of another module or compartment - **Access control** - control access to system resources and interaction between compartments | | Monolithic design | Component Design | | ---- | ---- | ---- | | enter of harmful user | ![[Pasted image 20240219190024.png]] | ![[Pasted image 20240219190038.png]] | | damage assesment | ![[Pasted image 20240219190032.png]] | ![[Pasted image 20240219190050.png]] | ##### Access Control The primary purpose of security mechanisms in a system is to control access to resources (like files, memory areas, processor time, devices, DB etc). In early system they had no access control all users were allowed to access any file by simply knowing its name. Access control became necessary with emergence of disk storage where many users could store files, therefore controlling access to disk files was probably the first widespread computer security concern. **Access Control** - is the process of mediating every request to resources and data maintenance by system and determining whether the request should be granted or denied based on a security policy ![[Pasted image 20240219190448.png]] **Requirement and assumptions** - the development of an AC system requires the definitions of regulations according to which access is to be controlled their implementation as functions executable by a computer system. System knows who the user is and authentication via name password and other credentials is needed. Access request pass through a gate keeper or the reference monitor therefore system must not allow monitor to be bypassed ![[Pasted image 20240219190833.png|inlR|500]] Formalisation phase allows the definition of formal model making it possible to define and prove security properties that system enforcing the models will enjoy, therefore by proving that the model is secure and that the mechanism correctly implements the model we can argue that the system is secure. **Access control types** - can be grouped into 2 major classes: - **Discretionary (DAC)** - authorisation-based access control, where users at their discretion can specify to the system who can access their objects/files. Discretionary access control policies are usually coupled with an administrative policy that defines who can specify authorisation/rule governing access control. - **Mandatory access control (MAC)** - where the system controls access based on mandated regulations determined by a central authority. ##### DAC Implements discretionary policies, which are based on identity of subject and identity of object involved, access control is left to the discretion of owner, and owner of the object can constrain who and how can access it. DAC pivots around the concept of user having control over system resource, where each system resource is assigned ownership by one or more entities. Also called **identity based access control** or **authorisation based access control**. **Advantages** are clear: simplicity, flexibility and ease of implementation. **Cons** are: There is no formal assurance concerning the flow of information. Examples for DAC: Password for file access A password-based access scheme is used to protect files by assigning to each file a password by its owner, then only users who know the password are able to access the file, usually there must exist two passwords for each file, one for controlling reading and one for controlling writing. It gets overwhelming when system with thousand files needs such protection, and it this system is only suitable for primary protection mechanisms in early systems. Problem are numerous: - Management problem - large organisation where users come and go daily a password based protection scheme for all files becomes impossible to manage - Revocation problem - there is no way to revoke one user's access to the file, without revoking everyone's access - Tracking problem - very hard to keep track who has access to the file since passwords are distributed manually without system's knowledge - Remembering problem - requiring the user to remember a separate password for each file is an unreasonable burden Example DAC: Access control Matrix | | File 1 | File 2 | File 3 | ... | File n | | ---- | ---- | ---- | ---- | ---- | ---- | | User 1 | read | write | - | ... | read | | User 2 | write | write | write | .... | - | | User 3 | - | - | - | ... | read | | User m | read | write | read | ... | read | Rows are set of subjects in system Columns are set of objects in system Matrix entry \[i, j\] is the right that subject has on object Implementation is done via Access Control List which store column of matrix with the resource. It allows user to hold a "ticket" for each resources, with 2 variants to store row of the matrix with user under OS control, or store unforgettable "ticket" in user space. Note: Access control lists are widely used often with groups, and in some aspects of capability concept are used in many systems. Access Control list can associate a list with each object, and check user/group against the list, it relies heavily on authentication meaning user needs to be authorised. Capabilities is an unforgeable ticket which is random bit sequences or is managed by OS, and can be passed from one process to another. Reference monitor checks the ticket and does not know the identity of the user/process. Access Control List use User ID which is inherited from a parent process. Where Capabilities are inherited (full or in part) from parent process | ACL | Capabilities | | ---- | ---- | | ![[Pasted image 20240219193927.png]] | ![[Pasted image 20240219193932.png]] | | Access right delegation is most commonly done by leting other process act under current User ID rather then asking owner to add permission to the list | - Access right delegation is done by having process pass capability at runtime meaning: - Capabilities involve passing a token or object (capability) at runtime, granting a process specific access rights. - A process can delegate its capabilities to another process, allowing the latter to access resources on its behalf | | Revocation is done by simply removing user or group from the list | - To revoke access in a capability system, the original possessor of the capability can attempt to reclaim or invalidate the capability from the process to which it was delegated. - Some systems may support revocation by tracking capabilities and ensuring appropriate bookkeeping. If the operating system recognizes which data is associated with a capability, revocation becomes feasible. - If a capability is shared among multiple resources, revocation may need to be applied to all or none of those resources. Capabilities can introduce indirection where a capability points to a pointer to a resource. If C -> P -> R (Capability points to Pointer, and Pointer points to Resource), revoking the capability can involve setting the pointer (P) to zero, rendering the capability ineffective. | **Biggest challenges** in access control - are complex mechanisms which require complex input, which is difficult to configure and maintain, therefore need for organisation is needed to simplify the problem. - **Grouped rights for resources** - involves grouping related resources, and creating hierarchy for rights or resources, meaning if user has already rights over specific group it could imply that it has right over other group. *Permission = right to resource* - **Roles** - is set of users to which is granted specific access and can be named such as: Admin, PowerUser, User, Guest. Role also indicates to creating a hierarchy partial order of roles, where each role gets permission of role bellow and list only new permissions given each role ![[Pasted image 20240219195021.png|inlR|300]]![[Pasted image 20240219195039.png|inlR|300]] - **Owner/Group/Other Technique** - are system defined access control where few bits of access control information are attached to each file indicating, owner of file, user belonging to the owner's group or project, special system users and rest of the world. In large system where users are grouped by project or department most access control needs are satisfied by this technique ![[Pasted image 20240219195955.png|inlR|400]] ##### Mandatory Access Control (MAC) Is a OS mechanism that controls access to object which an individual user can't alter, even subject and owner of the object can't determine whether access is granted to specific user, because system mechanism will check information associated with both the subject and the object to determine whether the subject should access the object. Rules describe the conditions under which access is allowed. It is also called rule-base policies "Zugriffsregeln" Example would be the law allows the fiscal authorities to have access on your bank account records. - Goal of MAC - is to preserve confidentiality and integrity of information, and prevent a user to change security attributes - Types of Mandatory Policies are: - secrecy policy which controls the direct and indirect flows of information to the purpose of preventing leakages to unauthorised subjects. - integrity policy which controls the direct and indirect flows of information to the purpose of preventing unauthorised altering of object Mandatory control can be used in conjunction with discretionary controls, which can serve as an additional and stronger restriction on access. **Example MAC: Multi-Level Security** Nearly all multi level security are variants of U.S. Department of Defence's multi-level security. They use security policy which is classification involving sensitivity levels and compartments, as well as preventing classified information leak to unclassified files. Group individuals and resources use some form of hierarchy to organise policy. ![[Pasted image 20240219201218.png|inlR|500]] Classification of personnel and data represent rank in compartment. It applies to subjects users or processes and objects documents and resources **Example MAC: Bell-LaPadula Model** Developed and formalised by David Bell and Leonard LaPadula, objective was confidentiality it have 2 properties: 1. **Simple property** (no-read-up-principle) - A subject S may read object O only if C(O) $\leq$ C(S) meaning you may only read bellow your classification 2. Confinement Property (or \*-Property) - A subject S with read access to O may write object P only if C(O) $\leq$ C(P) - you may only write above your classification You may only read bellow and write above ![[Pasted image 20240219202123.png|inlR|400]] **Example MAC: Biba Integrity Model** Developed by Biba, objective vas Integrity, or rules that preserve integrity of information and it has 2 properties: 1. **Simple integrity** (no-write-up-prinicple) 2. **Integrity confinement** (or \*-Property) (no-read-down-principle) You may only write bellow your classification and only read above your classification ![[Pasted image 20240219202109.png|inlR|400]] Problem since Biba and BLP are contradictory where BLP achieves confientiality since of only read down and write up policy while Biba achives integrity by read up and only write down. Only way to satisfy both models is only allow read and write at same classification. Remark: BLP is used more then Biba model Other concepts: - Separation of duty - if amount is over 10k check is only valid if signed by two authorised people, two people must be different and policy involves role memberships and inequality - Chinese Wall Policy - lawyers L1, L2 in Firm F are experts in baking, if bank B1 sues bank B2, L1 and L2 can each work for either B1 or B2 but no lawyer can work for opposite side in any case, making permission depending on use of other permissions. ##### Access control in Unix Each file is assigned access control list which grants permission to user IDs and owner, group and other. Processes are assigned User IDs which are inherited from when user creates process, although process can change UID with restricted set of option. There is also special root ID which doesn't have any access control restriction. Each file has an owner and group in Unix ![[Pasted image 20240219203322.png|inlR|300 ]] Permission is set by owner for read, write and execute as well as owner, group and other. It is all represented by vector of 4 octal values. Only owner and root can change permissions, this privilege cannot be delete or shared. Each Process has three IDS: - Real user ID (RUID) - which is same as user ID of parent process (unless changed) and it is used to determine which user started the process - Effective user ID (EUID) - is from set user ID bit on the file being executed, or sys call, it determines the permission of the process like file access and port binding. - Saved user ID (SUID) - is set so the previous EUID can be restored RID and EUID are used similarly Process Operation and IDs Root has ID of 0 and can access any file Fork inherit three IDs, while exec inherits of of file with setuid bit Setuid system calls can set EUID to ReaL ID or save ID, regardless of current EUID any ID if EUID=0 There exist 3 setuid bits on executable Unix file: 1. Setuid - set EUID of process to ID of file owner 2. Setgid - set EGID of process to GID of file 3. Sticky - **off** if user has write permission on directory then can rename or remove files even if not the owner. **on** only file owner directory owne and root can rename or remove file in the directory ![[Pasted image 20240219204045.png|inlR|400]] Best practices are to be careful with Setuid 0, since root can do anything follow principles of least privilege, change EUID when root privileges no longer are needed Good things in unix AC that some protection from most users is flexible enough to make things possible and main limitation is too tempting to use root privileges and no root privileges can be taken away. ##### Access Control In Windows Basic functionality is similar to Unix, meaning access can be specified for groups and users, which can read, write, modify, change owner and delete given files/directories. Although there are some additional concepts like tokens and security attributes, but in general Windows in AC is more flexible then Unix since it can define new permissions and can give some but not all administrative privileges. Sample Permission Options - SID is Identity similar to UID, but it is revision number an 48bit authority value which is made of Domain identifier and Relative Identifier (RID). Users, group, computers, domains and domain members all have SIDs **Permission Inheritance** - Static permission inheritance (Win NT) - initially subfolders inherit permissions of the parent folder, but folder and subfolder permissions can be changed independently, with option Replace permissions on subdirectories eliminates any difference in permissions - Dynamic permission inheritance (Win 2000) - child inherits parent permission which remain linked, parent changes are inherited except explicit settings, there opens a room for conflict since inherited and explicitly set permission are different, the resolution rules that positive permissions are additive and negative permissions takes priority **Tokens** - are security reference monitor that uses tokens to identify the security context of a process or thread. Security context like privileges, account and groups associated with the process thread. Impersonation token is used by thread to temporarily adopt a different security context usually of another user. SELinux is security enhanced Linux system by NSA - it enforces separation of information based on confidentiality and integrity requirements. Access control incorporated into major subsystem of the kernel, it limit tampering and bypassing of application security mechanisms and confine damage caused by malicious applications. SELinux security policy abstractions use type enforcement for each process to have an associated domain and each object has an associated type. Configuration files specify how domains are allowed to access type and allowable interactions and transactions between domains. Role based access control for each process has an associated role of separate system and user processes. Configuration files specify set of domains that may be entered by each role **Certification Standards** are created in Orange Book and developed by the US Department of Defense the document employs the concept of Trusted Computing Base TCB which is a combination of computer hardware and an operating system that supports untrusted applications and users. The document gives his own definition of computer security by introducing layers of trust. Common criteria is today's internationally recognised standard, which defines Evaluation Assurance Levels (EALs) and replaces orange book