Sie sind auf Seite 1von 12

Outline (may not finish in one lecture)

Access Control and Operating

Access Control Concepts Secure OS
System Security Matrix, ACL, Capabilities Methods for resisting
Multi-level security (MLS) stronger attacks

OS Mechanisms Assurance
Multics Orange Book, TCSEC
John Mitchell Ring structure Common Criteria
Amoeba Windows 2000
Distributed, capabilities
Unix Some Limitations
File system, Setuid Information flow
Windows Covert channels
File system, Tokens, EFS
SE Linux
Role-based, Domain type

Access control Access control matrix [Lampson]

Common Assumption Objects

System knows who the user is File 1 File 2 File 3 File n

User has entered a name and password, or other info
Access requests pass through gatekeeper User 1 read write - - read
OS must be designed monitor cannot be bypassed
User 2 write write write - -
Reference Subjects
monitor User 3 - - - read read
process ? Resource

User m read write read write read

Decide whether user can apply operation to resource

Two implementation concepts Capabilities

Access control list (ACL) File 1 File 2 Operating system concept
Store column of matrix User 1 read write - of the future and always will be
with the resource User 2 write write -
Capability Dennis and van Horn, MIT PDP-1 Timesharing
User 3 - - read
Hydra, StarOS, Intel iAPX 432, Eros,
User holds a ticket for
Amoeba: distributed, unforgeable tickets
each resource User m read write write
Two variations References
store row of matrix with user
unforgeable ticket in user space
Henry Levy, Capability-based Computer Systems
Access control lists are widely used, often with groups
Tanenbaum, Amoeba papers
Some aspects of capability concept are used in Kerberos,

ACL vs Capabilities ACL vs Capabilities
Access control list
Associate list with each object User U Capabilty c,d
Check user/group against list Process P Process P
Relies on authentication: need to know user
Capabilities User U Capabilty c
Capability is unforgeable ticket Process Q Process Q
Random bit sequence, or managed by OS
Can be passed from one process to another User U Capabilty c
Reference monitor checks ticket Process R Process R
Does not need to know identify of user/process

ACL vs Capabilities Roles (also called Groups)

Delegation Role = set of users
Cap: Process can pass capability at run time Administrator, PowerUser, User, Guest
ACL: ???? Assign permissions to roles; each user gets permission
Revocation Role hierarchy
ACL: Remove user or group from list Partial order of roles Administrator
Cap: Try to get capability back from process? Each role gets
permissions of roles below PowerUser
Possible in some systems if appropriate bookkeeping
OS knows what data is capability List only new permissions
If capability is used for multiple resources, have to User
given to each role
revoke all or none
Other details Guest

Groups for resources, rights Multi-Level Security (MLS) Concepts

Permission = right, resource Military security policy
Permission hierarchies Classification involves sensitivity levels, compartments
Do not let classified information leak to unclassified files
If user has right r, and r>s, then user has right s
Group individuals and resources
If user has read access to directory, user has read
access to every file in directory Use some form of hierarchy to organize policy
Other policy concepts
Big problem in access control Separation of duty
Complex mechanisms require complex input Chinese Wall Policy
Difficult to configure and maintain
Roles, other organizing ideas try to simplify problem

Military security policy Military security policy
Sensitivity levels Compartments Classification of personnel and data
Class = rank, compartment
Satellite data
Dominance relation
Middle East D1 D2 iff rank1 rank2
Israel and compartment1 compartment2
Top Secret
Secret Example: Restricted, Israel Secret, Middle East
Confidential Applies to
Restricted Subjects users or processes
Unclassified Objects documents or resources

Commercial version Bell-LaPadula Confidentiality Model

Product specifications When is it OK to release information?
Discontinued Two Properties (with silly names)
In production
Simple security property
A subject S may read object O only if C(O) C(S)
Internal *-Property
Proprietary A subject S with read access to O may write object P only
if C(O) C(P)

In words,
You may only read below your
classification and only write above
your classification

Picture: Confidentiality Biba Integrity Model

Read below, write above Read above, write below Rules that preserve integrity of information
Two Properties (with silly names)
Simple integrity property
Proprietary Proprietary A subject S may write object O only if C(S) C(O)
(Only trust S to modify O if S has higher rank )
S S A subject S with read access to O may write object P only
if C(O) C(P)
(Only move info from O to P if O is more trusted than P)
Public Public In words,
You may only write below your
classification and only read above your

Picture: Integrity Problem: Models are contradictory
Read above, write below Read below, write above Bell-LaPadula Confidentiality
Read down, write up
Biba Integrity
Proprietary Proprietary
Read up, write down
Want both confidentiality and integrity
S S May use Bell-LaPadula for some classification of
personnel and data, Biba for another
Otherwise, only way to satisfy both models is only allow
read and write at same classification
Public Public
In reality: Bell-LaPadula used more than Biba model
Example: Common Criteria

Other policy concepts Example OS Mechanisms

Separation of duty Multics
If amount is over $10,000, check is only valid if Amoeba
signed by two authorized people Unix
Two people must be different
Policy involves role membership and
SE Linux (briefly)
Chinese Wall Policy
Lawyers L1, L2 in Firm F are experts in banking
If bank B1 sues bank B2,
L1 and L2 can each work for either B1 or B2
No lawyer can work for opposite sides in any case
Permission depends on use of other permissions
These policies cannot be represented using access matrix

Multics Multics time period

Operating System Timesharing was new concept F.J. Corbato
Designed 1964-1967 Serve Boston area with one 386-based PC
MIT Project MAC, Bell Labs, GE
At peak, ~100 Multics sites
Last system, Canadian Department of Defense,
Nova Scotia, shut down October, 2000
Extensive Security Mechanisms
Influenced many subsequent systems
E.I. Organick, The Multics System: An Examination of Its Structure, MIT Press, 1972

Multics Innovations Multics Access Model
Segmented, Virtual memory Ring structure
Hardware translates virtual address to real address A ring is a domain in which a process executes
High-level language implementation Numbered 0, 1, 2, ; Kernel is ring 0
Written in PL/1, only small part in assembly lang Graduated privileges
Shared memory multiprocessor Processes at ring i have privileges of every ring j > i

Multiple CPUs share same physical memory

Relational database Each data area or procedure is called a segment
Segment protection b1, b2, b3 with b1 b2 b3
Multics Relational Data Store (MRDS) in 1978
Process/data can be accessed from rings b1 b2
Security A process from rings b2 b3 can only call segment at
restricted entry points
Designed to be secure from the beginning
First B2 security rating (1980s), only one for years

Multics process Amoeba Server port Obj # Rights Check field

Multiple segments Distributed system

Segments are dynamically linked Multiple processors, connected by network
Linking process uses file system to find segment
Process on A can start a new process on B
A segment may be shared by several processes
Location of processes designed to be transparent
Multiple rings
Procedure, data segments each in specific ring Capability-based system
Access depends on two mechanisms Each object resides on server
Per-Segment Access Control
Invoke operation through message to server
File author specifies the users that have access to it
Send message with capability and parameters
Concentric Rings of Protection
Sever uses object # to indentify object
Call or read/write segments in outer rings
Sever checks rights field to see if operation is allowed
To access inner ring, go through a gatekeeper
Check field prevents processes from forging capabilities
Interprocess communication through channels

Capabilities Server port Obj # Rights Check field

Unix file security
Owner capability Each file has owner and group
When server creates object, returns owner cap. Permissions set by owner setid
All rights bits are set to 1 (= allow operation)
Check field contains 48-bit rand number stored by server Read, write, execute
- rwx rwx rwx
Derived capability Owner, group, other
Represented by vector of ownr grp othr
Owner can set some rights bits to 0
Calculate new check field four octal values
XOR rights field with random number from check field Only owner, root can change permissions
Apply one-way function to calculate new check field
Server can verify rights and check filed This privilege cannot be delegated or shared
Without owner capability, cannot forge derived capability Setid bits Discuss in a few slides
Protection by user-process at server; no special OS support needed

Question Effective user id (EUID)
Owner can have fewer privileges than other Each process has three Ids (+ more under Linux)
What happens? Real user ID (RUID)
User gets access? same as the user ID of parent (unless changed)
User does not? used to determine which user started the process
Effective user ID (EUID)
from set user ID bit on the file being executed, or sys call
Prioritized resolution of differences
determines the permissions for process
if user = owner then owner permission file access and port binding
else if user in group then group permission Saved user ID (SUID)
else other permission So previous EUID can be restored
Real group ID, effective group ID, used similarly

Process Operations and IDs Setid bits on executable Unix file

Root Three setid bits
ID=0 for superuser root; can access any file Setuid set EUID of process to ID of file owner
Fork and Exec Setgid set EGID of process to GID of file
Inherit three IDs, except exec of file with setuid bit Sticky
Off: if user has write permission on directory, can rename
Setuid system calls or remove files, even if not owner
seteuid(newid) can set EUID to On: only file owner, directory owner, and root can
Real ID or saved ID, regardless of current EUID rename or remove file in the directory
Any ID, if EUID=0

Details are actually more complicated

Several different calls: setuid, seteuid, setreuid

Example Compare to stack inspection

Owner 18
RUID 25 SetUID Careful with Setuid !
A 1
Can do anything that
; owner of file is
; allowed to do B 1
exec( ); Be sure not to
Owner 18
-rw-r--r-- Take action for
; RUID 25 untrusted user C 1
file EUID 18
; Return secret data to
i=getruid() untrusted user

Owner 25 setuid(i);
-rw-r--r-- read/write ; RUID 25 Note: anything possible if root; no middle
file ; EUID 25
ground between user and root

Setuid programming Unix summary
We talked about this before Were all very used to this
Be Careful! So probably seems pretty good
Root can do anything; don t get tricked We overlook ways it might be better
Principle of least privilege change EUID when Good things
root privileges no longer needed Some protection from most users
Setuid scripts Flexible enough to make things possible
This is a bad idea Main bad thing
Historically, race conditions Too tempting to use root privileges
Begin executing setuid program; change contents of
program before it loads and is executed No way to assume some root privileges without all
root privileges

Access control in Windows (NTFS) Sample permission options

Some basic functionality similar to Unix SID
Specify access for groups and users Identity (replaces UID)
Read, modify, change owner, delete SID revision number
Some additional concepts 48-bit authority value
variable number of
Tokens Relative Identifiers
Security attributes (RIDs), for uniqueness
Users, groups,
computers, domains,
domain members all
More flexibility than Unix have SIDs
Can define new permissions
Can give some but not all administrator privileges

Permission Inheritance Tokens

Static permission inheritance (Win NT) Security Reference Monitor
Initially, subfolders inherit permissions of folder uses tokens to identify the security context of a
Folder, subfolder changed independently process or thread
Replace Permissions on Subdirectories command Security context
Eliminates any differences in permissions privileges, accounts, and groups associated with
Dynamic permission inheritance (Win 2000) the process or thread
Child inherits parent permission, remains linked Impersonation token
Parent changes are inherited, except explicit settings thread uses temporarily to adopt a different
Inherited and explicitly-set permissions may conflict security context, usually of another user
Resolution rules
Positive permissions are additive
Negative permission (deny access) takes priority

Security Descriptor Example access request
Information associated with an object Access
User: Mark
Group1: Administrators
who can perform what actions on the object token Group2: Writers
Several fields Access request: write
Header Revision Number Action: denied
Control flags
Descriptor revision number Owner SID User Mark requests write permission
Control flags, attributes of the descriptor Group SID
Descriptor denies permission to group
E.g., memory layout of the descriptor DACL Pointer
Security SACL Pointer Reference Monitor denies request
SID of the object's owner descriptor Deny
SID of the primary group of the object Writers
Read, Write
Two attached optional lists: Allow
Discretionary Access Control List (DACL) users, groups, Mark
System Access Control List (SACL) system logs, .. Read, Write

Impersonation Tokens (setuid?) Encrypted File Systems (EFS, CFS)

Process uses security attributes of another Store files in encrypted form

Client passes impersonation token to server Key management: users key decrypts file
Client specifies impersonation level of server Useful protection if someone steals disk
Anonymous Windows EFS
Token has no information about the client User marks a file for encryption
Identification Unique file encryption key is created
server obtain the SIDs of client and client's privileges, but
server cannot impersonate the client
Key is encrypted, can be stored on smart card
Unix CFS [Matt Blaze]
server identify and impersonate the client Transparent use
Delegation Local NFS server running on "loopback" interface
lets server impersonate client on local, remote systems Key protected by passphrase

Q: Why use crypto file system? SELinux Security Policy Abstractions

General security questions Type enforcement
What properties are provided? Each process has an associated domain
Against what form of attack? Each object has an associated type
Crypto file system Configuration files specify
What properties? How domains are allowed to access types
Allowable interactions and transitions between domains
Secrecy, integrity, authenticity, ?
Against what kinds of attack? Role-based access control
Someone steals your laptop? Each process has an associated role
Someone steals your removable disk? Separate system and user processes
Someone has network access to shared file system? configuration files specify
Depends on how file system configured and used Set of domains that may be entered by each role

Secure Operating Systems Sample Features of Trusted OS
Extra mechanisms for extra security Mandatory access control
Follow design and implementation procedures MAC not under user control, precedence over DAC
Object reuse protection
Review of design and implementation
Write over old data when file space is allocated
Maintenance procedures Complete mediation
Prevent any access that circumvents monitor

Will discuss Audit

See next slide
Mechanisms associated with secure OS
Intrusion detection
Standards for certification
Anomaly detection
Mostly used by government, some commercial interest
Learn normal activity, Report abnormal actions
Attack detection
Recognize patterns associated with known attacks

Audit Trusted path

Log security-related events Spoofing
Protect audit log Fool user/process into thinking they are
Write to write-once non-volatile medium communicating with secure part of system
Audit logs can become huge Intercept communication
Trusted path
Manage size by following policy
Storage becomes more feasible Mechanisms to prevent spoofing
Analysis more feasible since entries more meaningful Special key sequence for passwd command intercepted
by trusted kernel (e.g, ctrl-alt-delete)
Example policies Allow some actions only at boot time, before user
Audit only first, last access by process to a file processes loaded
Do not record routine, expected events
E.g., starting one process always loads

Kernelized Design SELinux

Trusted Computing Base User space Security-enhanced Linux system (NSA)
Hardware and software for User Enforce separation of information based on
enforcing security rules process confidentiality and integrity requirements
Mandatory access control incorporated into the
major subsystems of the kernel
Reference monitor Limit tampering and bypassing of application security
Part of TCB Reference

All system calls go through monitor Confine damage caused by malicious applications
reference monitor for TCB
security checking
OS kernel
Most OS not designed this
way Kernel space

Why Linux? Rainbow Series
Open source
Already subject to public review DoD Trusted Computer Sys Evaluation Criteria (Orange Book)
This by itself does not guarantee security Audit in Trusted Systems (Tan Book)
NSA can review source, modify and extend Configuration Management in Trusted Systems (Amber Book)
Hope to encourage additional operating system Trusted Distribution in Trusted Systems (Dark Lavender Book)
security research Security Modeling in Trusted Systems (Aqua Book)
Released under the same terms and conditions as Formal Verification Systems (Purple Book)
the original sources.
Covert Channel Analysis of Trusted Systems (Light Pink Book)
includes documentation and source code
many more

Assurance methods Orange Book Criteria (TCSEC)

Testing Level D
Can demonstrate existence of flaw, not absence No security requirements
Formal verification Level C For environments with cooperating users
Time-consuming, painstaking process C1 protected mode OS, authenticated login, DAC,
Validation security testing and documentation (Unix)
C2 DAC to level of individual user, object
Requirements checking
initialization, auditing (Windows NT 4.0)
Design and code reviews
Level B, A
Sit around table, drink lots of coffee,
Module and system testing All users and objects must be assigned a security
label (classified, unclassified, etc.)
System must enforce Bell-LaPadula model

Levels B, A (continued) Orange Book Requirements (TCSEC)

Level B Security Policy
B1 classification and Bell-LaPadula Accountability
B2 system designed in top-down modular way, Assurance
must be possible to verify, covert channels must
be analyzed
B3 ACLs with users and groups, formal TCB must
be presented, adequate security auditing, secure
crash recovery
Next few slides: details not important
Level A1
Main point: Higher levels require more work ,
Formal proof of protection system, formal proof
documentation and configuration management are
that model is correct, demonstration that impl
part of the criteria
conforms to model, formal covert channel analysis

Common Criteria Protection Profiles
Three parts Requirements for categories of systems
CC Documents Subject to review and certified
Protection profiles: requirements for category of systems Example: Controlled Access PP (CAPP_V1.d)
Functional requirements
Security functional requirements
Assurance requirements
Authentication, User Data Protection, Prevent Audit Loss
CC Evaluation Methodology
Security assurance requirements
National Schemes (local ways of doing evaluation) Security testing, Admin guidance, Life-cycle support,
Endorsed by 14 countries Assumes non-hostile and well-managed users
Replaces TCSEC Does not consider malicious system developers
CC adopted 1998
Last TCSEC evaluation completed 2000

Evaluation Assurance Levels 1 4 Evaluation Assurance Levels 5 7

EAL 1: Functionally Tested EAL 5: Semiformally Designed and Tested
Review of functional and interface specifications Formal model, modular design
Some independent testing Vulnerability search, covert channel analysis
EAL 2: Structurally Tested EAL 6: Semiformally Verified Design and Tested
Analysis of security functions, incl high-level design Structured development process
Independent testing, review of developer testing EAL 7: Formally Verified Design and Tested
EAL 3: Methodically Tested and Checked Formal presentation of functional specification
Development environment controls; config mgmt Product or system design must be simple
EAL 4: Methodically Designed, Tested, Reviewed Independent confirmation of developer tests
Informal spec of security policy, Independent testing

Example: Windows 2000, EAL 4+

Evaluation performed by SAIC
Used Controlled Access Protection Profile
Level EAL 4 + Flaw Remediation
EAL 4 represents the highest level at which
products not built specifically to meet the
requirements of EAL 5-7 ought to be evaluated.
(EAL 5-7 requires more stringent design and
development procedures )
Flaw Remediation
Evaluation based on specific configurations
Produced configuration guide that may be useful

Is Windows is Secure? Limitations of Secure OS
Good things Noninterference
Design goals include security goals Actions by high-level users (secret, top secret)
Independent review, configuration guidelines should not be observable by low-level users
(unclassified, )
Difficult to achieve and prove, not impossible
Secure is a complex concept
What properties protected against what attacks?
Typical installation includes more than just OS Covert Channels
Many problems arise from applications, device drivers Can user of system deliberately communicate
Windows driver certification program secret information to external collaborator?

Noninterference Example: Smart Card

High Hig Signing

inputs h key
outpu Tamper-proof
Low Low Challenge Response
inputs outpu ts input output

Covert Channels Outline (did not finish in one lecture)

Butler Lampson Access Control Concepts Secure OS

Matrix, ACL, Capabilities Methods for resisting
Difficulty achieving confinement (paper on web) stronger attacks
Multi-level security (MLS)
Communicate by using CPU, locking/unlocking file, Assurance
sending/delaying msg, OS Mechanisms
Multics Orange Book, TCSEC
Gustavus Simmons Ring structure Common Criteria
Cryptographic techniques make it impossible to Amoeba Windows 2000
detect presence of a covert channel Distributed, capabilities
Unix Some Limitations
File system, Setuid Information flow
Windows Covert channels
File system, Tokens, EFS
SE Linux
Role-based, Domain type