Controlling a ComputerRichard Newman

Computer ComponentsMotherboard

– CPU

– RAM/daughterboards

– CMOS

– ROM with BIOS

– I/O circuits, connectors

Power Supply

Peripherals– Keyboard

– Monitor/video

– Mouse

– Drives

– Network Interface(s)

Program Execution- Fetch-decode-execute cycle

– Fetch instruction from RAM using Program Counter– Load into Instruction Register– Decode instruction in IR– Execute instruction in IR

• Load additional operand(s) into data register(s)

• Set PC to next instruction depending on length

• Perform actual instruction

- Process Image– Text segment (code/control)– Data (heap) segment (alloc'ed memory and globals)

• Usually grows “upward” toward stack

– Stack (dynamic – procedure calls)• Usually grows “downward” toward heap

Hardware Protection

- Tagged Memory– Owner– Data/instructions– Read/write access

- Protected Instructions– Mode bit(s)– Must be in proper mode to execute certain insructions– Protects raw I/O, clock, memory access, etc.

- Virtual Memory– User processes general logical addresses– LA converted to physical address by MMU/memory map– Prevents one process from generating physical address that does

not belong to it– Access to non-local memory through system calls

Buffer OverflowBuffers

– Memory locations used for transferring data– Often data multiply handled to adjust for variable speed/bursts or

for efficiency reasons

Process makes procedure call– Activation frame is pushed onto the stack– PC set to first instruction of called procedure– When procedure done, return to next instruction of caller

Activation Frame– Return address of calling procedure– Parameters passed in (set by caller)– Results passed out (set by called routine)– Local variables (declared in called procedure)

If called procedure does not limit length of input, can overwrite parts of AF in stack

Buffer Overflow - 2

If called procedure does not check length of input read into buffer, can overwrite return PC value

PC value can be set to point to location in stack (not code segment)

Location pointed to by new PC value can hold attack code (e.g., shell script)

Code is executed with access levels of process that made call with buffer overflow

-> Counter measures- check/limit length of read buffers- tagged memory (don't execute stack locations)- least privilege

Access Control Strategies- Islands

– Isolation and mediation– Untrusted process given “sandbox”

- Vaults– Access to wider (more dangerous) resources requested

individually with system mediation on a case-by-case basis– Required for access to shared resources

- Puzzles– Process uses secret or hidden information to access desired

resources – must be impractical to find it or to guess– Cryptography, steganography, security through obscurity

- Patterns– Access patterns compared with known bad patterns, blocked or

audited if match (virus signatures)– Normal access patterns noted and deviations detected

(anomalies)

Chain of ControlWhen computer starts, it runs software that enforces desired

security policyOther software started either

– Complies with security policy, or– Is prevented from violating the policy by system restrictions and/or

mediation

Subversion of CoC– Boot from different source (e.g., CD-ROM)– Trojan Horse (get user/admin to execute attack code)– Attack process vulnerability (force legit process to execute attack

code – e.g., buffer overflow)

OS Security Features

CPU scheduling– Prevent “hogging” CPU– Kernel mode context switch to isolate process execution

Isolate memory allocation to processes and protect– Fence– Base/Bounds– Virtual Memory – page/segment table

Isolate I/O to/from processes– Ptty's, exclusive access

Process authorization based on owner ID– User I&A – Process “protection domain” to decide access

Audit – Log “interesting” events

Access Control

Shared Resources– CPU(s) – serially shared– Memory – may have concurrent access or serial re-use– Devices – access through service processes

Shared Memory– Easiest with Segmented Memory – Multiple process segment tables have entry pointing to same

memory segment– Most often for read-only segments (e.g., text)– Can also be used for shared data segments – race conditions

Access rights implementation/enforcement– In segment table – set up as read-only– Via Access Matrix

Access Control MatrixConceptual model for access control specification

– Rows - “domains” or processes– Columns - “objects” - including (passivated) processes– Cells – define access rights domain has for object

ACM State– Defined by contents of ACM cells and ACM dimensions – State change by

• Add/remove object

• Add/remove domain/process

• Add/remove right from cell [i,j]

– Request for access mediated through RM consulting ACM– RM follows guarded commands as part of system

HRU Undecidability– From initial state, can a state be reached with r in ACM[i,j]?– Undecidable via TM simulation

Access Control Matrix - 2

ACM is too large– Domain may include <ruid, rgid, euid, egid> or more– Objects include all files, devices, may be sub-file level– Inescapable Mediation requires checking each time– ACM too big for RAM!!!

ACL – access control lists– “Column” of ACM – associated with object – (domain, rights-set) pairs – Bring ACL into RAM along with object control block– Only need ACLs for actively used objects

CL – capability lists– “Row” of ACM – associated with domain or process– (object, rights-set) pairs– Only need CLs for active processes

Access Control Matrix - 3

Hybrid approach– ACL used to decide access rights on OPEN of object– Capability added to CL of process during OPEN– Don't have to populate CL for all possible objects– Can limit access for process to least privilege

Time-of-check to time-of-use problem– Access rights checked at one time– Nature of object changes before use (the old switcheroo)– Need (implicit) capability “locked” for object and CL

Security Policy and Implementation

Policy = What you wantImplementation = What you get

– Every system has both, whether known or not

Model = Means of expression of set of policies– Mathematical – Graphical– Transactional

Model constraints expressability of policiesImplementation constrains enforceability of policies

Writing a Security Policy

1. Each statement is numbered (allows cross-referencing)– May be outline numbered if complicated

2. Each statement uses the word “shall” – “may” used for optional parts– “should” used for optional but only if strong reasons for not doing

3. Policy statements should be testable– Determine if implementation enforces policy for compliance

4. Each statement identifies prioritized risks it addresses5. Statements should state policies positively (i.e., “do this”)

– Avoid negative (“Don't do that”) - hard to test– Avoid global (“all, any”) - hard to test– May not always be possible

Security Control Categories

Physical– Physical boundaries that resist penetration – e.g., wall, door,

Faraday cage, etc.

Mechanical – Protection from connections that can be changed only through

mechanical intervention – e.g., unplugging network cable

Logical– Structured rules enforced by program, e.g., rwx bits

Functional– Design and operation of functions in s/w, e.g., s/w tests for

condition

Procedural– Explicit operating procedures for humans, e.g., key distribution

Cryptographic– Cryptographic transformation of data/code

Implementation: Security Control List

Number each control– As with policies

Specify control category– Clarify its nature

Describe control– What it is– Configuration– How to use

Relationship to policy– cross-reference

Checking Policy, Controls

Verify each risk has one or more associated policiesReview policies associated with each risk to assure coverageVerify each policy has associated controlsReview controls associated with each policy to assure adequate

enforcement If controls are incomplete for policy, expand controls