1. Introduction to Information Security , Spring Lecture 9: Secure Architecture Principles, Access Control
Avishai Wool Slides credit: Eran Tromer, John Mitchell, Stanford Max Krohn, MIT Ian Goldberg and Urs Hengartner, University of Waterloo

2. Secure Architecture Principles: Isolation and Least Privilege

3. Basic idea: Isolation
A Seaman's Pocket-Book, (public domain)

4. Principles of Secure Design
Compartmentalization
Isolation
Principle of least privilege
Defense in depth
Use more than one security mechanism
Secure the weakest link
Fail securely
Keep it simple

5. Principle of Least Privilege
Ability to access or modify a resource
Principle of Least Privilege
A system module should only have the minimal privileges needed for intended purposes
Requires compartmentalization and isolation
Separate the system into independent modules
Limit interaction between modules

6. Example: Android process isolation
Android application sandbox
Isolation: Each application runs with its own UID in own VM
Provides memory protection
Communication protected using Unix domain sockets
Only ping, zygote (spawn another process) run as root
Interaction: reference monitor checks permissions on inter-component communication
Least Privilege: Applications announces permission
Whitelist model – user grants access
Questions asked at install time, to reduce user interruption

7. Access control
Concepts

8. ? Access control Assumptions Resource User process
System knows who the user is
Authentication via name and password, other credential
Access requests pass through gatekeeper (reference monitor)
System must not allow monitor to be bypassed
Reference
monitor
Resource ?
User process
access request
policy

9. Access control matrix [Lampson]
Subjects users, processes
Objects files, sockets, resources
File 1
File 2
File 3 …
File n
User 1
read
write -
User 2
User 3
User m

10. Two implementation concepts
Access control list (ACL)
Store column of matrix
with the resource
Capability
User holds a “ticket” for
each resource
Two variations
store row of matrix with user, under OS control
unforgeable ticket in user space
File 1
File 2 …
User 1
read
write -
User 2
User 3
User m
Read
Access control lists are widely used, often with groups
Some aspects of capability concept are used in many systems

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

12. ACL vs Capabilities User U Process P Process P Capabilty c,d,e User U
Process Q
Process Q
Capabilty c,e
User U
Process R
Capabilty c
Process R

13. ACL vs Capabilities Delegation Revocation
Cap: Process can pass capability at run time
ACL: Try to get owner to add permission to list?
More common: let other process act under current user
Revocation
ACL: Remove user or group from list
Cap: Try to get capability back from process?
Possible in some systems if appropriate bookkeeping
OS knows which data is capability
If capability is used for multiple resources, have to revoke all or none …
Indirection: capability points to pointer to resource
If C  P  R, then revoke capability C by setting P=0

14. Roles (also called Groups)
Role = set of users
Administrator, PowerUser, User, Guest
Assign permissions to roles; each user gets permission
Role hierarchy
Partial order of roles
Each role gets
permissions of roles below
List only new permissions
given to each role
Administrator
PowerUser
User
Guest

15. Role-Based Access Control
Individuals
Roles
Resources
engineering
Server 1
Server 2
marketing
Server 3
human res
Advantage: users change more frequently than roles

16. Access control
Unix

17. Unix access control File has access control list (ACL)
Grants permission to user ids
Owner, group, other
Process has user id
Inherit from creating process
Process can change id
Restricted set of options
Special “root” id
Bypass access control restrictions
File 1
File 2 …
User 1
read
write -
User 2
User 3
User m
Read

18. Unix file access control list
Each file has owner and group
Permissions set by owner
Read, write, execute
Owner, group, other
Represented by vector of
four octal values (rwxr-xr-x)  public directory or executable (rw-r--r--)  public file (rw )  private file
Only owner, root can change permissions
This privilege cannot be delegated or shared
Setid bits – Discuss in a few slides
setid -
rwx
rwx
rwx
ownr
grp
othr

19. Owner can have fewer privileges than other
Question
Owner can have fewer privileges than other
What happens?
Owner gets access?
Owner does not?
Prioritized resolution of differences
if user = owner then owner permission
else if user in group then group permission
else other permission

20. Process effective user id (EUID)
Each process has three Ids (+ more under Linux)
Real user ID (RUID)
same as the user ID of parent (unless changed)
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
determines the permissions for process
file access and port binding
Saved user ID (SUID)
So previous EUID can be restored
Real group ID, effective group ID, used similarly

21. Process Operations and IDs
Root
ID=0 for superuser root; can access any file
Fork and Exec
Inherit three IDs, except exec of file with setuid bit
Setuid system calls
seteuid(newid) can set EUID to
Real ID or saved ID, regardless of current EUID
Any ID, if EUID=0
Details are actually more complicated
Several different calls: setuid, seteuid, setreuid

22. setid bits on executable Unix file
Three setid bits
Setuid – set EUID of process to ID of file owner
Setgid – set EGID of process to GID of file
Sticky
Off: if user has write permission on directory, can rename or remove files, even if not owner
On: only file owner, directory owner, and root can rename or remove file in the directory

23. setuid example Owner 18 RUID 25 SetUID …; program exec( ); Owner 18
i=getruid()
setuid(i);
-rw-r--r--
RUID 25
file
read/write
EUID 18
Owner 25
RUID 25
-rw-r--r--
read/write
EUID 25
file

24. setuid programming Be Careful with Setuid 0 !
Root can do anything; don’t get tricked
Principle of least privilege – change EUID when root privileges no longer needed

25. Access Control
Windows

26. Access control in Windows (since NTFS)
Some basic functionality similar to Unix
Specify access for groups and users
Read, modify, change owner, delete
Some additional concepts
Tokens
Security attributes
Generally
More flexibility than Unix
Can define new permissions
Can give some but not all administrator privileges

27. Identify subject using SID
Security ID (SID)
Identity (replaces UID)
SID revision number
48-bit authority value
variable number of Relative Identifiers (RIDs), for uniqueness
Users, groups, computers, domains, domain members all have SIDs

28. Each process has set of tokens
Security context
Privileges, accounts, and groups associated with the process or thread
Presented as set of tokens
Reference Monitor
Uses tokens to identify the security context of a process or thread
Impersonation token
Used temporarily to adopt a different security context, usually of another user

29. Each object has security descriptor
Security descriptor, associated with an object, specifies who can perform what actions on the object
Fields:
Header
Descriptor revision number
Control flags, attributes of the descriptor
E.g., memory layout of the descriptor
SID of the object's owner
SID of the primary group of the object
Two attached optional lists:
Discretionary Access Control List (DACL) controls access by users, groups, …
System Access Control List (SACL) controls logging of access to system logs

30. Example access request
User: Mark
Access token
Access request: write
Action: denied
Group1: Administrators
Group2: Redhaired
Revision Number
Control flags
User Mark requests write permission
Descriptor denies permission to group
Reference Monitor denies request
Owner SID
Group SID
DACL Pointer
Security descriptor
SACL Pointer
Deny
ACE1
Redhaired
Order of ACEs in ACL matters. Windows reads ACL until permission is Granted or Denied, then stops.
Read, Write
ACE2 (Access Control Entry
Allow
Mark
Read, Write

31. Impersonation Tokens (compare to setuid)
Process adopts security attributes of another
Client passes impersonation token to service
Client specifies impersonation level of service
Anonymous
The service can impersonate the client but the impersonation token does not contain any information about the client.
Identification
The service can get the identity of the client and use this information in its own security mechanism, but it cannot impersonate the client.
Impersonation
The service can impersonate the client (on local computers).
Delegation
The service can impersonate the client on local and remote computers.

32. Access control policies

33. Multi-Level Security (MLS) Concepts
Military security policy
Classification involves sensitivity levels, compartments
Do not let classified information leak to unclassified files
Group individuals and resources
Use some form of hierarchy to organize policy
Other policy concepts
Separation of duty
“Chinese Wall” Policy (managing conflicts of interests)

34. Military security policy
Compartments
Sensitivity levels
Satellite data
Micronesia
Middle East
Israel
בצה"ל
סודי ביותר
סודי
שמור
מוגבל
בלמ"ס
Top Secret
Secret
Confidential
Restricted
Unclassified

35. Example: military security policy
Classification of personnel and data
Class = rank, compartment
Dominance relation
C1  C2 iff rank1  rank2
and compartment1  compartment2
Example: Restricted, Israel  Secret, Middle East
Applies to
Subjects – users or processes
Objects – documents or resources

36. Example: commercial policy
Product specifications
Discontinued
In production
OEM
Internal
Proprietary
Public

37. Generalizing: lattices
A dominance relationship that is transitive and antisymmetric defines a lattice
For two levels a and b, maybe neither a ≥ b nor b ≥ a
However, for every a and b, there is a lowest upper bound u for which u ≥ a and u ≥ b, and a greatest lower bound l for which a ≥ l and b ≥ l
There are also two elements U and L that dominate/are dominated by all levels
In next slide’s example, U = (“Top Secret”, {“Middle East”, “Micronesia”}) L = (“Unclassified”, )‏

38. Example Lattice (“Top Secret”, {“Middle East”, “Micronesia”}),
(“Secret”, {“Micronesia”})
(“Unclassified”, )‏

39. Bell-LaPadula Confidentiality Model
1976, Multics
When is it OK to release information?
Two properties
No read up
A subject S may read object O only if C(O)  C(S)
No write down
A subject S with read access to O may write to object P only if C(O)  C(P)
You may only read below your classification and write above your classification

40. Bell-LaPadula Confidentiality Model
“No read up” – intuitive
“No write down” – forbid high-classified reader to copy and reduce classification
Special “Trusted user” allowed to write-down
Mandatory Access Control: protect even against malicious software / users / trojan horses who try to violate policy.
In contrast: Linux & Windows use Discretionary Access Control: owners can set permissions

41. Picture: Confidentiality
Read below, write above S
Public
Proprietary
Read above, write below
Proprietary S
Public

42. Bell-LaPadula Gaps Focus on Confidentiality, not much else
Assigning classification to all files and user – hard.
Classification of data data changes over time
Data tends to migrate up: a trusted user has to continually "downgrade" it.
Bruce Schneier: "Data sometimes have a higher classification in aggregate than each datum does individually”

43. Biba Integrity Model
1975
Goal: preserve integrity of information (dual to confidentiality)
Two properties
No write up
A subject S may write object O only if C(S)  C(O)
(Only trust S to modify O if S has higher rank …)
No read down
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)
You may only write below your classification and read above your classification

44. Picture: Integrity S S Read above, write below Public Proprietary
Read below, write above
Proprietary S
Public

45. Biba Integrity Model
1975
High level information is most reliable  readable by all
Lowest level information is least reliable  only low-level users can read it

46. Problems with MLS Covert channels
Declassification (when OK to violate strict policy?)
Composability (e.g, one-time-pad)
Aggregation (many “low” facts may enable deduction of “high” information)
Overclassification (label creep)
Incompatibilies (e.g., upgraded files “disappear”)
Polyinstantiation (maintaining consistency when different users have different view of the data, and perhaps even see “cover stories”)

47. These policies cannot be represented using access matrix
Other policy concepts
Separation of duty
If amount is over $10,000, check is only valid if signed by two authorized people
Two people must be different
Policy involves role membership and 
Chinese Wall Policy
Lawyers L1, L2 in same firm
If company C1 sues C2,
L1 and L2 can each work for either C1 or C2
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

48. Policies: further reading
Anderson, Stajano, Lee, Security Policies
Levy, Capability-Based Computer Systems

49. Information Flow Control

50. Information Flow Control
An information flow policy describes authorized paths along which information can flow
For example, Bell-La Padula describes a lattice-based information flow policy

51. Program-level IFC
Input and output variables of program each have a (lattice-based) security classification S() associated with them
For each program statement, compiler verifies whether information flow is secure
For example, x = y + z is secure only if S(x) ≥ lub(S(y), S(z)), where lub() is lowest upper bound
Program is secure if each of its statements is secure

52. Implicit information flow
Conditional branches carry information about the condition:
secret bool a;
public bool b; …
b = a;
if (a) {
b = 1;
} else {
b = 0; }
Possible solution: assign label to program counter and include it in every operation. (Too conservative!)

53. IFC: Implementation approaches
Language-based IFC (JIF & others)
Compile-time tracking for Java, Haskell
Static analysis
Provable security
Label creep (false positives)
Dynamic analysis
Language / bytecode / machine code
Tainting
False positives, false negatives
Performance
Hybrid solutions
OS-based DIFC (Asbestos, HiStar, Flume)
Run-time tracking enforced by a trusted kernel
Works with any language, compiled or scripting, closed or open

54. Difficulties with Information Flow Control
Label creep Examples:
Branches
Logically-false flows
“Doesn’t really matter”
Declassification
Example: encryption
Catching all flows
Exceptions (math division by 0, null pointer, out of bounds access…)
Signals
Covert channels