Introduction to Computer Security

Transcription

1 Introduction to Computer Security Instructor: Mahadevan Gomathisankaran 1

2 Introduction So you can specify a well-thought-out policy and a concrete model now what? Now it s time for a system design and implementation! What to get out of this discussion: You deal with OSes all the time, even if you re not developing one understand your basic environment! Techniques have withstood the test of time well, and are best practices for secure system development. Many applications have their own security controls, so benefit from these techniques! 2

3 Design Principles Accepted principles from Saltzer and Schroeder, 1975 Principle of Least Privilege Each user / process has only the capabilities necessary Realizations: Servers (web server, mail server,...) should not run as root Any privileged program should drop privileges ASAP If not possible, consider separating into privileged / non-privileged components Consider chroot jail Principle of Economy of Mechanism Security mechanisms should be as simple as possible Idea: Code can be verified Realizations: Central security monitor for access decisions rather than scattered 3

4 More Design Principles Principle of Complete Mediation All accesses should be checked for proper authorization Do not assume previously verified authorization is still good Example: Don t assume a user selected only from validated options on a previous page/screen. Time of check to time of use (TOCTTOU) violations Principle of Open Design Security should not depend on secrecy of design Security through obscurity is a bad practice! Note: Obscurity isn t a bad thing, but security shouldn t rely on it Example: Secret keys for playing DVDs hidden in player software Principle of Separation of Privilege System should not grant permission based on a single condition Physical world example: multiple signatures for checks Computer example: multifactor authentication 4

5 More Design Principles Principle of Least Common Mechanism Users and tasks should be isolated from each other Keep web server separate from mail server separate from database server... Isolate public services from private network (use a DMZ) Principle of Psychological Acceptability (Book calls this Ease of Use ) Security mechanisms should not make a resource more difficult to access Auto screen lock with too short a timeout might be turned off by users Over-strict password policy might lead to people writing down passwords Book adds: Permission based Default condition should be denial of access 5

6 General OS Functions 6

7 Features of Ordinary OSes User authentication Protection of memory File and I/O device access control Allocation/Access Control for objects Enforcement/Management of sharing Guarantee of fair service Interprocess communication and synchronization Protection of OS protection data 7

8 Trusted OS Functions 8

9 Features in Trusted OSes Identification and Authentication Mandatory and Discretionary Access Control Object Reuse Protection Complete Mediation All accesses are checked Trusted Path Know who you re interacting with! Accountability and Audit Audit Log Reduction Intrusion Detection 9

10 Features in Trusted OSes Object Reuse: Example: User A finishes with file1 and frees file1 OS adds file1 labels file1 dirty and adds it to resource pool User B requests a new file creation from OS OS allocates space including file1 to User B If malicious, user B can read the data in file1 Could be file, memory, processor registers, disk, tape Solution: OS clears every space before reallocation 10

11 Features in Trusted OSes Accountability and Audit Accountability: Keep track of security related events 11

12 Features in Trusted OSes Audit Log Reduction: List each event and person responsible for deletion, addition or change. Problems: Difficulties with volume and analysis. Solution: audit only the opening (first access) and closing (last access) files or similar objects. Needle in a haystack phenomenon: Solution: Let system admin review and analyze audit log for an exception or write a program to detect exceptions in the audit logs is this really possible? 12

13 Features in Trusted OSes Intrusion Detection: Detect security lapses by the following: Analyze normal flow to generate normal usage patterns Trigger an alarm when a usage is out of pattern 13

14 Kernelized Design Kernel (nucleus core): Lowest level of the OS Performs the lowest level operations (e.g. synchronization, IPC, message passing, interrupt handling) Security kernel: Enforces the security mechanisms of the OS Provides security interfaces among h/w, OS and other parts 14

15 Kernelized Design cont d Reasons to embed security functions in security kernel: Coverage Separation Unity Modifiability Compactness Verifiability 15

16 Security Kernel Further refinement of monolithic OS kernel OS can be huge Debian 2.2 release of Linux has roughly 55 million SLOC (source lines of code) Windows XP is estimated at 40M SLOC Kernel is probably about 10% of these # s Imagine how hard this is to analyze! Hardware All subject-object accesses go through the security kernel (even accesses from within the OS kernel!) 16

17 Security Kernel - Reference Monitor The part of security kernel that controls access to objects Usually not a program but a group of access controls for devices, files, memory, IPC, etc. Must be Tamperproof: Impoosible to weaken/disable Unbypassable: always invoked during object access requests Analyzable: small enough to be analyzed and tested 17

18 Security Kernel - Reference Monitor Can control access if It cannot be modified or circumvented by a rogue process It is the single point through which all access requests pass As size and complexity increases, the likelihood of correct behavior for reference monitor decreases. So, keep the reference monitor small and simple. 18

19 Security Kernel - Reference Monitor 19

20 Useful/Common Design: Rings Sometimes called the onion model Centralized design of critical functions Simplicity allows for thorough analysis Simplicity leads to a higher level of assurance Hardware 20

21 Hardware Support for Ring Design Intel x86 Privilege Model: Protection Rings Figure 4-3 from the Intel Architecture Software Developer s Manual Operating System Kernel Operating System Services (Device Drivers, Etc.) Applications Level 0 Level 1 Level 2 Level 3 Notes: A program can call a higher privilege level segment only through a well-controlled gate Unfortunately: Most current OSes only use levels 0 and 3 21

22 What Goes in Center? Related concepts (definitions from Glossary of Computer Security Terms from NCSC/DoD) Reference Monitor: An access-control concept that refers to an abstract machine that mediates all accesses to objects by subjects. Security Kernel: The hardware, firmware, and software elements of a TCB that implement the reference monitor concept. It must mediate all accesses, be protected from modification, and be verifiable as correct. Trusted Computing Base (TCB): The totality of protection mechanisms within a computer system, including hardware, firmware, and software, the combination of which is responsible for enforcing a security policy. A TCB consists of one or more components that together enforce a unified security policy over a product or system. The ability of a TCB to enforce correctly a unified security policy depends solely on the mechanisms within the TCB and on the correct input by system administrative personnel of parameters (e.g., a user s clearance level) related to the security policy. 22

23 Trusted Computing Base (TCB) Non-TCB TCB User applications Utilities User request interpreter User process coordination, synchronization User environment: objects, names (e.g., files) User I/O Procedures, user processes Creation and deletion of user objects Directories Extended types Segmentation, paging, memory management Primitive I/O Basic operations / access control Clocks, timing Interrupt handling Hardware: registers, memory Capabilities Figure 5-13 from textbook TCB is everything necessary to enforce the security policy in OS In addition to access control, includes audit, authentication, IPC, policy setting/loading Note that hardware is always considered part of the TCB 23

24 Elements of TCB h/w: Processors, memory, registers, I/O devices Some notion of processes so as to separate and protect security critical processes Primitive files e.g. security access control db and identification/authentication data Protected memory so as to protect reference monitor against tampering IPC so that to pass data to activate other parts of TCB e.g. reference monitor passes data to audit routine 24

25 TCB Functions Process activation: Process activation/deactivation in multiporgramming environment. Execution domain switching: Process in one domain invoke processes in other domains to obtain more sensitive data/services. Memory protection: Each domain has code and data in memory. TCB must monitor memory references to ensure domain secrecy and integrity I/O Operation Can cross all domains 25

26 TCB Implementation Combined Security Kernel / OS 26

27 TCB Implementation Separate Security Kernel 27

28 Separation / Isolation Physical: Different processes use different h/w facilities Temporal Time based allocation of CPU Cryptographic Different processes can run simultaneously because unauthorized users cannot access sensitive data in the clear Logical (Isolation) A process (e.g. a reference monitor) separates one user s objects from other. 28

29 Virtual Memory Spaces Basic idea: Each process sees memory that makes it think it s the only thing running on the machine. Other processes don t have addresses, so no way to access directly so don t need access controls Gives the impression of physical separation Example: IBM MVS/ESA operating system Designed for IBM 390 series mainframes MVS = Multiple Virtual Storage ESA = Enterprise Systems Architecture Trusted Operating Systems 29

30 Virtualization Multiple Virtual Memory Spaces 30

31 Virtual Machines Conventional OS 31

32 Virtual Machines 32

33 Layered OS 33

34 Modules in Different Layers 34