Outline

Access Control and Operating

u Access Control u Secure OS
System Security • Matrix, ACL, Capabilities • Methods for resisting
• Multi-level security (MLS) stronger attacks
u OS Policies u Assurance
• Multics • Orange Book, TCSEC
John Mitchell – Ring structure • Common Criteria
• Unix • Windows 2000
– File system, Setuid certification
• Windows u Some Limitations
– File system, Tokens, EFS • Information flow
• SE Linux • Covert channels
– Role-based
– Domain type enforcement

Access control Access control matrix [Lampson]

uCommon Assumption
• 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
– Global property; OS must be designed so that this is true
User 2 write write write - -
Reference
monitor User 3 - - - read read
User
process ? Resource …

User m read write read write read

Decide whether user can apply operation to resource

Two implementation concepts Capabilities

uAccess control list (ACL) File 1 File 2 … uOperating system concept
• Store column of matrix User 1 read write - • “… of the future and always will be …”
with the resource User 2 write write - uExamples
uCapability User 3 - - read • Dennis and van Horn, MIT PDP-1 Timesharing
• Allow user to hold a … • Hydra, StarOS, Intel iAPX 432, Amoeba, Eros, …
“ticket” for each resource
User m read write write
• Roughly: store row of
matrix with the user
uReference
• Henry Levy, Capability-based Computer Systems
http://www.cs.washington.edu/homes/levy/capabook/
Access control lists are widely used, often with groups
Some aspects of capability concept are used in Kerberos, …

1
Roles (also called Groups) Groups for resources, rights
uRole = set of users uPermission = 〈right, resource〉
• Administrator, PowerUser, User, Guest uGroup related resources
• Assign permissions to roles; each user gets permission uHierarchy for rights or resources
uRole hierarchy • If user has right r, and r>s, then user has right s
• Partial order of roles Administrator • If user has read access to directory, user has read
• Each role gets access to every file in directory
PowerUser
permissions of roles below
• List only new permissions User uBig problem in access control
given to each role • Complex mechanisms require complex input
Guest
• Difficult to configure and maintain
• Roles, other organizing ideas try to simplify problem

Multi-level Security Concepts Military security policy

uMilitary security policy uSensitivity levels uCompartments
– Classification involves sensitivity levels, compartments
– Do not let classified information leak to unclassified files Satellite data
uGroup individuals and resources Afghanistan
• Use some form of hierarchy to organize policy Middle East
Israel
uOther concepts
Top Secret
• Separation of duty
Secret
• Chinese Wall Policy
Confidential
Restricted
Unclassified

Military security policy Commercial version

uClassification of personnel and data Product specifications
• Class = 〈rank, compartment〉 Discontinued
In production
uDominance relation
OEM
• D1 ≤ D2 iff rank1 ≤ rank2
and compartment1 ⊆ compartment2 Internal
Proprietary
• Example: 〈Restricted, Israel〉 ≤ 〈Secret, Middle East〉 Public
uApplies to
• Subjects – users or processes
• Objects – documents or resources

2
Bell-LaPadula Confidentiality Model Picture: Confidentiality
uWhen is it OK to release information? Read below, write above Read above, write below
uTwo Properties (with silly names)
• Simple security property
– A subject S may read object O only if C(O) ≤ C(S)
Proprietary Proprietary
• *-Property
– A subject S with read access to O may write object P only
if C(O) ≤ C(P) S S

uIn words,
• You may only read below your classification and Public Public
only write above your classification

Biba Integrity Model Picture: Integrity

uRules that preserve integrity of information Read above, write below Read below, write above
uTwo Properties (with silly names)
• Simple integrity property
– A subject S may write object O only if C(S) ≥ C(O)
Proprietary Proprietary
(Only trust S to modify O if S has higher rank …)
• *-Property
– A subject S with read access to O may write object P only S S
if C(O) ≥ C(P)
(Only move info from O to P if O is more trusted than P)
uIn words, Public Public
• You may only write below your classification and
only read above your classification

Problem: Models are contradictory Other policy concepts

uBell-LaPadula Confidentiality uSeparation of duty
• Read down, write up • If amount is over $10,000, check is only valid if
uBiba Integrity signed by two authorized people
• Read up, write down • Two people must be different
• Policy involves role membership and ≠
uWant both confidentiality and integrity
• Only way to satisfy both models is only allow read
uChinese Wall Policy
and write at same classification • 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
In reality: Bell-LaPadula used more than Biba model
– No lawyer can work for opposite sides in any case
Example: Common Criteria • Permission depends on use of other permissions

3
Example OS Mechanisms Multics
uMultics uOperating System
uUnix • Designed 1964-1967
– MIT Project MAC, Bell Labs, GE
uWindows
• At peak, ~100 Multics sites
uSE Linux (briefly) • Last system, Canadian Department of Defense,
Nova Scotia, shut down October, 2000
u Extensive Security Mechanisms
• Influenced many subsequent systems

http://www.multicians.org/security.html

Multics time period Multics Innovations

uTimesharing was new concept uSegmented, Virtual memory
• Serve Boston area with one 386-based PC • Hardware translates virtual address to real address
uHigh-level language implementation
• Written in PL/1, only small part in assembly lang
uShared memory multiprocessor
• Multiple CPUs share same physical memory
uRelational database
• Multics Relational Data Store (MRDS) in 1978
uSecurity
• Designed to be secure from the beginning
• First B2 security rating (1980s), only one for years

Multics Access Model Unix file security

uRing structure uEach file has owner and group
• A ring is a domain in which a process executes uPermissions set by owner setid
• Numbered 0, 1, 2, … ; Kernel is ring 0 • Read, write, execute
• Graduated privileges - rwx rwx rwx
• Owner, group, other
– Processes at ring i have privileges of every ring j > i ownr grp othr
• Represented by vector of
uSegments four octal values
• Each data area or procedure is called a segment uOnly owner, root can change permissions
• Segment protection 〈b1, b2, b3〉 with b1 ≤ b2 ≤ b3 • This privilege cannot be delegated or shared
– Process/data can be accessed from rings b1 … b2
– A process from rings b2 … b3 can only call segment at uSetid bits – Discuss in a few slides
restricted entry points

4
Question Effective user id (EUID)
uOwner can have fewer privileges than other uEach 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
uPrioritized 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
uReal group ID, effective group ID, used similarly

Process Operations and IDs Setid bits on executable Unix file

uRoot uThree setid bits
• ID=0 for superuser root; can access any file • Setuid – set EUID of process to ID of file owner
uFork 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
uSetuid 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

uDetails are actually more complicated

• Several different calls: setuid, seteuid, setreuid

Example Compare to stack inspection

Owner 18
RUID 25 SetUID uCareful with Setuid !
• Can do anything that A 1
…; program 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
read/write
file …; EUID 18 – Return secret data to
i=getruid() untrusted user
Owner 25 setuid(i);
-rw-r--r-- read/write …; RUID 25
…; EUID 25 Note: anything possible if root; no middle
file
ground between user and root

5
Setuid programming Unix summary
uWe talked about this before … uWe’re all very used to this …
uBe 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 uGood things
root privileges no longer needed • Some protection from most users
uSetuid scripts • Flexible enough to make things possible
• This is a bad idea uMain bad thing
• Historically, race conditions • Too tempting to use root privileges
– Begin executing setuid program; change contents of
• No way to assume some root privileges without all
program before it loads and is executed
root privileges

Access control in Windows (NTFS) Sample permission options

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

Permission Inheritance Tokens

uStatic permission inheritance (Win NT) uSecurity 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 uSecurity context
– Eliminates any differences in permissions • privileges, accounts, and groups associated with
uDynamic permission inheritance (Win 2000) the process or thread
• Child inherits parent permission, remains linked uImpersonation 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

6
Security Descriptor Example access request
uInformation associated with an object Access
User: Mark
Group1: Administrators
• who can perform what actions on the object token Group2: Writers
uSeveral 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
• Two attached optional lists: Read, Write
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)

uProcess uses security attributes of another uStore files in encrypted form

• Client passes impersonation token to server • Key management: user’s key decrypts file
uClient specifies impersonation level of server • Useful protection if someone steals disk
• Anonymous uWindows – 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
• Key is encrypted, can be stored on smart card
server cannot impersonate the client
• Impersonation uUnix – 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

uGeneral security questions uType enforcement
• What properties are provided? • Each process has an associated domain
• Against what form of attack? • Each object has an associated type
uCrypto file system • Configuration files specify
– How domains are allowed to access types
• What properties?
– Allowable interactions and transitions between domains
– Secrecy, integrity, authenticity, … ?
• Against what kinds of attack? uRole-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

7
Secure Operating Systems Sample Features of Trusted OS
uExtra mechanisms for extra security u Mandatory access control
• MAC not under user control, precedence over DAC
uFollow design and implementation procedures
u Object reuse protection
uReview of design and implementation • Write over old data when file space is allocated
uMaintenance procedures u Complete mediation
• Prevent any access that circumvents monitor
u Audit
Will discuss • See next slide
• Mechanisms associated with secure OS u 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

uLog security-related events uSpoofing
uProtect audit log • Fool user/process into thinking they are
• Write to write-once non-volatile medium communicating with secure part of system
• Intercept communication
uAudit logs can become huge
• Manage size by following policy
uTrusted path
– 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

uTrusted Computing Base User space uSecurity-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
uReference monitor – Limit tampering and bypassing of application security
• Part of TCB mechanisms
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
http://www.nsa.gov/selinux/

8
Why Linux? Rainbow Series
uOpen 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.
– includes documentation and source code Covert Channel Analysis of Trusted Systems (Light Pink Book)
… many more

http://www.radium.ncsc.mil/tpep/library/rainbow/index.html

Assurance methods Orange Book Criteria (TCSEC)

uTesting uLevel D
• Can demonstrate existence of flaw, not absence • No security requirements
uFormal verification uLevel C For environments with cooperating users
• Time-consuming, painstaking process • C1 – protected mode OS, authenticated login, DAC,
u“Validation” security testing and documentation (Unix)
• Requirements checking • C2 – DAC to level of individual user, object
initialization, auditing (Windows NT 4.0)
• Design and code reviews
– Sit around table, drink lots of coffee, … uLevel B, A
• 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)

uLevel B uSecurity Policy
• B1 – classification and Bell-LaPadula uAccountability
• B2 – system designed in top-down modular way, uAssurance
must be possible to verify, covert channels must
be analyzed uDocumentation
• B3 – ACLs with users and groups, formal TCB must
be presented, adequate security auditing, secure
crash recovery
uNext few slides: details not important …
uLevel 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

9
Common Criteria Protection Profiles
uThree parts uRequirements for categories of systems
• CC Documents • Subject to review and certified
– Protection profiles: requirements for category of systems uExample: 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, …
uEndorsed by 14 countries • Assumes non-hostile and well-managed users
uReplaces TCSEC • Does not consider malicious system developers
• CC adopted 1998
• Last TCSEC evaluation completed 2000
http://www.commoncriteria.org/

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 uEAL 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+

uEvaluation performed by SAIC
uUsed “Controlled Access Protection Profile”
uLevel 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
uEvaluation based on specific configurations
• Produced configuration guide that may be useful

10
Is Windows is “Secure”? Limitations of Secure OS
uGood things uNoninterference
• 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, …)
uBut …
• 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 uCovert 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 High Signing

inputs outputs key
Tamper-proof
Process
hardware
Low Low Challenge Response
inputs outputs input output

Covert Channels Outline

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

11