Transcript Processes

Controlling a Computer
Richard Newman
Computer Components
Motherboard
–
–
–
–
–
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 Overflow
Buffers
–
–
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 Control
When computer starts, it runs software that enforces desired
security policy
Other 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
–
Log “interesting” events
Audit
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 Matrix
Conceptual 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 want
Implementation = 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 policies
Implementation 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 addresses
5. 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 policies
Review policies associated with each risk to assure coverage
Verify each policy has associated controls
Review controls associated with each policy to assure adequate
enforcement
If controls are incomplete for policy, expand controls