220 likes | 438 Views
Protection and Security. Computer Security. External Security: Physical access to computer facility Interface Security: Authentication of user Internal Security: Protection: control of access within computer systems
E N D
Computer Security • External Security: Physical access to computer facility • Interface Security: Authentication of user • Internal Security: • Protection: control of access within computer systems • Communication security: control of information on communication lines between computer systems • File security: control of stored information
Potential Security Violations • Unauthorized information release: Unauthorized person can read information or use computer program • Unauthorized information modification: Unauthorized person can change information • Unauthorized denial of service: Unauthorized person prevents authorized users from accessing system (including overload, change in scheduling algorithms, etc.)
Policies and mechanisms; Protection domain • Policies and mechanisms • Policies: what should be done Security policies: which user can have access to what resources • Mechanisms: how it should be done Protection: mechanisms that control user access to system resources • Protection vs. security: Protection is a mechanism and security is a policy. • Protection domain of a process - Process domain: • Resources that can access • Operations it can use on these resources - Protection domain changes when control moves to another process - Policy: process should access only resources it needs for its task
Design Principles for Secure Systems (Saltzer and Schroeder) • Economy: Protection mechanism should be economical, i.e. low development cost and low system overhead • Complete mediation: every request to access an object should be validated • Open design: protection mechanism should work even if its design is well known • Separation of privileges: protection mechanism should require two conditions to allow access • Least privilege: a process should receive only minimum access rights required to complete its task • Least common mechanism: minimum shared mechanism between users. Shared mechanisms (variables) can become information path • Acceptability: Protection mechanism should be easy to use • Fail-safe defaults: Default case should be denial of access.
The Access Matrix Model • Model components • Current objects: set of entities, ‘O’, to which access is to be controlled Examples: files, memory pages, devices • Current subjects: set of entities, ‘s’, that access current objects (s o) Example: (process, domain) pair • Generic rights/rules: access rights that subjects can have to objects: R={r1, r2,…,rm} Examples: read, write, execute, own, block
The access matrix model (cont.) • Protection state of a system Triplet (S, O, P) Where P is the access matrix
Enforcing a Security Policy • A security policy is enforced by validating every user access for appropriate access rights Subject Object Object S Monitor O • Subject ‘S’ requests access ‘’ to object ‘O’ • Protection system gives (S, , O) to monitor for ‘ O’ • Monitor validates access rights of ‘S’ to ‘O if P [s,o] then access permitted else access denied Example:
Implementations of the Access Matrix (1) Capability-based method: - Decompose the access control matrix by rows and delete null entries - A row has access rights of a subject to objects (2) Access control list method: - Decompose the access control matrix by columns and delete null entries - A column has access rights of all subjects to an object (3) Lock-key method: - Combination of capability-based and access control list methods
(1) Capability-Based Method • Capability: Tuple (O, P[S,O]) • Each subject assigned a list of capabilities, one for each object it is allowed to access • Capability structure: - Object descriptor: points of object - Access rights: list of all access rights the subject is allowed on the object Object Descriptor Access Rights (read, write, execute)
(1) Capabilities-Based Method (cont.) • Principles: • Each subject has a collection of capabilities, one for each object, to which has access • Each object is protected by a guard (monitor), which holds object identifier • When a subject presents a capability that matches identifier, access is allowed • Model of a descriptor-based capability system with authentication mechanism 1. User presents id and password 2. System authenticates user 3. System creates a process S and assigns it capabilities in respective catalog 4. Process S can access all segments for which has capabilities
(1) Capabilities-Based Method (cont.) • Capability-based addressing
(1) Capabilities-Based Method (cont.) • Concepts: • Integrate capabilities with main memory addressing mechanisms • Keep separate capability information from object location info. (to allow simultaneous access to shared objects) • Effective address: capability id of object + offset within object • Operation: • Search capability list vs. id • Validate access • Search object table w. object descriptor • Physical location = base + offset • Advantages: relocatability and sharing • Example: IBM system/38
Implementation considerations Protection of capabilities - Issues: capabilities should be protected against unauthorized changes - Solutions: (a) tagged approach, (b) partitioned approach (a) Tagged approach: · Additional bits (flag) to each memory Location and processor register On - capability Off - ordinary data (user data or instruction) Separate instructions can modify locations if ‘On’; not available to users · Examples: Burroughs B6700, Rice Research Computer (b) Partitioned approach: · Separate partitions within object (segments), for capabilities and ordinary data · Separate processor registers also · Users cannot access segments and registers with capabilities · Examples: Plessey system and Chicago Magic Number Machine
• Advantages of Capabilities - Efficiency: easy test of access rights - Simplicity: simple implementation of addressing - Flexibility: ease of defining access rights
Issues With Capabilities • Control of propagation: - Issue: how to control propagation of capabilities once the object owner has given a capability to another subject - Options: · Add a ‘copy bit’ to each capability · Provide a depth counter incremented/decremented w. each copy • Review: - Issue: difficult to implement review of access, i.e. identification of all subjects which can access an object - Option: partitioned approach makes it easier • Revocation of access rights: - Issue: once a capability is given to a subject, it is difficult to revoke - Options: destroy copy of object or indirect addressing Garbage collection: - Issue: when all capabilities for an object disappear, object has to be removed - Options: keep count of copies of capabilities & detect zero • Domain switching - Issue: how does the set of capabilities change when subject changes domains - Option: ‘enter’ capability
Revocation of Capabilities • Capabilities are granted to subject • A subject who has a capability may want to give a copy to another subject • Problem: after giving a capability to another subject the initial subject may want to revoke it (take it back) • Solution: - Owner of object X creates C – capability that points indirectly to descriptor for X - Owner of object X gives C to other subjects - To revoke it, X is removed
Domain Switching • Processes may need to switch from one set of capabilities (domain) to another set (domain) to perform a task. • Domain switching with ‘enter’ capabilities (Dennis & Van Horn) - Enter capability points to capability list for procedure to be called (entry point in a protected subsystem) - When entry point is called, domain is switched to that of called procedure; domain restored at procedure return