1. Access Control Concepts

2. Access Control
What is access control?
SECURITY INNOVATION ©2003

3. Access Control
Provides limits on who can do what with objects on the computer
Can’t happen without identification and authentication
Is not the same as identification and authentication
Consider access as a lock on door
Access control requires attestation
SECURITY INNOVATION ©2003

4. Policy-Based Control of:
Access Control
Policy-Based Control of:
WHO has access to specific systems
WHAT they can do with them, and
WHEN they are allowed access
- Our security policies drive who has access, what they can do with the access and the amount they are allowed to access.
SECURITY INNOVATION ©2003

5. Access Control Layers:
Technical
Physical
Administrative
- Our policies cover three layers
SECURITY INNOVATION ©2003

6. Administrative Access Controls
Security Policies & Procedures
Security Awareness & Training
Separation of Duties
Hiring Procedures
Employee Termination Policy
Disaster Recovery & Contingency Plan
User Registration for Computer Access
SECURITY INNOVATION ©2003

7. Physical Access Controls
Network Segregation
Perimeter Security
Security Guards
Badge Systems
Biometric Access Controls
Closed Circuit TV Monitoring
Sensors & Alarms
SECURITY INNOVATION ©2003

8. Technical (Logical) Controls
Administrative and physical access controls are based on traditional security threats and thus are well understood
Technical or logical access controls mirror new software systems technology and the evolving threat model. For these reasons a discussion of technical controls is more complex and we address access control within this context.
SECURITY INNOVATION ©2003

9. Technical (Logical) Controls
In general technical controls involve….
Access Control Software
Passwords
Smart Cards
Encryption
System Access
Network Access
SECURITY INNOVATION ©2003

10. Access Control
Aspects of IT-security that we try to manage through access control are:
Confidentiality
Integrity
Accessibility
Known security policies are restricted to confidentiality and integrity
- The CIA model
SECURITY INNOVATION ©2003

11. Analogy of Organizational Security
Multi-level security policies (MLS-policies)
Different levels of security
E.g. top secret, secret, confidential, public
Relating security levels
To subjects (persons) and objects (rooms or items)
Control
Access right is only granted if person has the appropriate authorization, i.e. security level
- To help us think about logical controls we can view it in the context of organizational security
SECURITY INNOVATION ©2003

12. Access Control
Protection objects: system resources for which protection is desirable
Memory, file, directory, hardware resource, software resources, etc.
Subjects: active entities requesting accesses to resources
User, owner, program, etc.
Access mode: type of access
Read, write, execute
SECURITY INNOVATION ©2003

13. Access Control Requirement
Cannot be bypassed
Enforce least-privilege and need-to-know restrictions
Enforce organizational policy
SECURITY INNOVATION ©2003

14. Access Control
Access control: ensures that all direct accesses to object are authorized
Protects against accidental and malicious threats by regulating the reading, writing and execution of data and programs
Need:
Proper user identification and authentication
Information specifying the access rights is protected form modification
SECURITY INNOVATION ©2003

15. Access Control Access control components:
Access control policy: specifies the authorized accesses of a system
Access control mechanism: implements and enforces the policy
Separation of components allows to:
Define access requirements independently from implementation
Compare different policies
Implement mechanisms that can enforce a wide range of policies
SECURITY INNOVATION ©2003

16. Closed v.s. Open Systems Closed system Open System (minimum privilege)
(maximum privilege)
Access requirements
Access
requirements
Allowed
accesses
Exists Rule?
Disallowed
accesses
Exists Rule?
yes no no
yes
Access
permitted
Access
denied
Access
permitted
Access
denied
SECURITY INNOVATION ©2003

17. Access Control Access Control Active subjects: Passive objects:
Reference monitor
Active subjects:
e.g. processes, persons, groups ….
Passive objects:
e.g. data, memory banks, ...
SECURITY INNOVATION ©2003

18. How It Works A Subject – User or Process Request for Access
Reference Monitor – Decides on the Access
Reference Monitor Grants or Denies Access Request
Object – File / Printer / Nodes on Network
SUBJECT
OBJECT
REFERENCE MONITOR E D B C
SECURITY INNOVATION ©2003

19. Program Execution Program User X Monitor Network Disk Memory
SECURITY INNOVATION ©2003

20. Reference Monitor Makes access control work You can tell it
What a subject is allowed to do
What may be done with an object
In order to specify these things, you need to know all the possibilities, or you need to define things narrowly so that what you don't know doesn’t become allowed
SECURITY INNOVATION ©2003

21. Reference Monitors Single level Easy to implement…..BUT
May become a bottle-neck…
IF the access-control monitor is defeated, THEN all accesses are vulnerable
SECURITY INNOVATION ©2003

22. Ideal Reference Monitor
Real
most things
limited
Sees everything a program is about to do before it does it
Can instantly and completely stop program execution (or prevent action)
Has no other effect on the program or system
Can we build this?
Probably not unless we can build a time machine...
SECURITY INNOVATION ©2003

23. Protecting the Reference Monitor
It must not be possible to circumvent the reference monitor by corrupting it
Mechanisms
Type checking
Sandboxing: run processes in isolation
Software fault isolation: rewrite memory access instructions to perform bounds checking
User/Kernel modes
Segmentation of memory (OS resources aren’t part of virtual memory system)
SECURITY INNOVATION ©2003

24. Example Reference Monitors
Operating Systems
File system
Memory (virtual memory, separate address spaces)
Firewalls
Regulate network access
Java Virtual Machine
Regulates Java programs’ resource usage
Operate at different levels of abstraction
Interface (Subjects, Objects, Actions) varies
SECURITY INNOVATION ©2003

25. Reference Monitors Cannot enforce all Security Policies
Some policies depend on:
Knowing about the future
If the program charges the credit card, it must eventually ship the goods
Knowing about all possible executions
Information flow – can’t tell if a program reveals secret information without knowing about other possible executions
SECURITY INNOVATION ©2003

26. Access Control You want to protect some of the files you create
Is confidentiality an issue ?
Operating systems are designed to protect users from each other
Is integrity an issue ?
Terminology
An active subject wishes to use an access operation on a passive object.
(Sam wishes to read the production log)
The same entity can sometimes be either subject or object
(Sam wishes to execute the production program
The production program wishes to read the production log)
We could specify what the subject is allowed to do, or what may be done with the object
SECURITY INNOVATION ©2003

27. Access Control - Modes
There is a lot of computing history behind the four access modes
Execute (usually includes Read capability)
Read
Append (blind write)
Write -which includes Read capability
Note that these modes do not directly allow for entities (say an active user) to create objects, and to grant access modes to that object
Sam needs to create a file for the latest production report, and needs all members of the production team to have read access to that file
SECURITY INNOVATION ©2003

28. Basic Access Control 1 : Type of file. 2 – 4 : Owner’s permission.
5 – 7 : Group’s permission.
8 – 10 : Other’s permission.
PERMISSION
MEANING
- rwx rwx rwx
File. Everyone can read, write and execute this.
- rwx r-x r-x
File. Everyone can read and execute this but only the owner can write to it.
- r-- r
File. The owner and everyone in his group can only read this file, but the others have no access to it.
d rw- rw- rw-
Directory. Everyone can read and write. No one including the owner can traverse it.
l rwx r-x r-x
Link. The permissions for a link generally do not matter.
SECURITY INNOVATION ©2003

29. Access Control List UNIX
An access control list (ACL) is an ordered list of access control entries that define the protections that apply to an object and its properties
ACLs entry contains
Attributes:
Defines special file modes
Base permissions:
Reflect the basic access rights
Extended permissions:
specify, permit, deny
SECURITY INNOVATION ©2003

30. Access Control List ACL Entries Description
1. attributes: setuid,setgid,stickybit
Special file modes.
2. base permissions
Standard Unix file permissions.
3. owner(owner_user): rwx
owner and access rights
4. (owner_group): r-x
group and access rights
5. others: r--
other's rights
6. extended permissions
Additional ACL entries.
7. enabled
enabled or disabled
8. permit --x u:some_user, g:some_group
Permits access to the specified user-group combination in a boolean AND manner.
9. deny rwx g:a_group
Forbids access to the specified user-group combination in a boolean AND manner.
SECURITY INNOVATION ©2003

31. Auditing
Is a feature which provides accountability to all system activities from file access to network and database
Each audit event such as user login is formatted into fields such as the event type, user id, file names and time
Audit events
Administrative event class
Security administrator events
System administrator events
Operator events
Audit event class
Describes the operation of the audit system itself
SECURITY INNOVATION ©2003

32. Audit Trail
Record of both completed and attempted access and service chronological record of system activities
Enables reconstruction and examination of the sequence of events and changes in audit event
Monitoring system changes
Files system permission & checksum should be set, snapshots taken & made read only
Snapshots are made regularly and compared with the original for changes
Eg: tripwire, rdist utility, securemax (from open Vision), ESM….
SECURITY INNOVATION ©2003

33. Windows 2000 File System Supports two file system NTFS Vs FAT
FAT (File Allocation Table)
File system does not record security information such as owner or access permission of a file or directory
NTFS (New Technology Files System)
Supports a variety of multi-user security models
NTFS Vs FAT
Fault tolerance
Access Control by directory or file
Can compress individual or directories
POSIX support
SECURITY INNOVATION ©2003

34. Windows 2000 Auditing
Windows 2000's object access is an important source of OS-level information about how users employ your network. This category can track the source, time, and method of access to files, folders, registry keys, and printers. It can gather specific details about the logon session under which an access attempt occurred or the application through which a user tried to open an object. Object-access events can be linked to corresponding logon or process-tracking events.
SECURITY INNOVATION ©2003

35. Windows 2000 Access Control
Each object has two Access Control Lists.
A discretionary Access Control List (DACL)
A system Access Control List (SACL).
Windows 2000 auditing is able to track object access at both the system level and the object level. This is accomplished by first enabling the Audit object access category for success and failure events. Second, you need to enable auditing for each object you want to monitor.
SECURITY INNOVATION ©2003

36. Discretionary Access Control List (DACL)
The DACL controls who can access the object and how.
the object's Access Control Settings
permissions for only one user or one group at a time
SECURITY INNOVATION ©2003

37. System Access Control List (SACL).
The SACL defines the actions for which Windows 2000 audits an object. An object's SACL consists of access control entries (ACEs). An ACE defines exactly which types of access Windows 2000 records in the Security log when a specified user or group accesses the object.
audit the Everyone group's successful attempts to gain write access and failed attempts to gain read access.
SECURITY INNOVATION ©2003

38. Access Control List Data structure of an ACL
ACL size - # of bytes of memory allocated
ACL Revision – revision # for the ACL’s data structure
ACE Count - # of ACE’s in the ACL
SECURITY INNOVATION ©2003

39. Access Control Entries
Contains the following access control information
A security identifier (SID)
An access mask – specifies access rights
A set of bit flags that determines which child objects can inherit the ACE
A flag that indicates the type of ACE
SECURITY INNOVATION ©2003

40. ACE Types 3 Generic types Object-Specific ACE types Type Description
Access-denied
Used in a DACL to deny access.
Access-allowed
Used in a DACL to allow access.
System-audit
Used in a SACL to log attempts to access.
Type
Description
Access-denied, object-specific
Used in a DACL to deny access to a property or property set, or to limit inheritance to a specified type of child object.
Access-allowed, object-specific
Used in a DACL to allow access to a property or property set, or to limit inheritance to a specified type of child object.
System-audit, object-specific
Used in a SACL to log attempts to access a property or property set, or to limit inheritance to a specified type of child object
SECURITY INNOVATION ©2003

41. Access Rights Generic Access Rights Standard Access Rights
Other rights like, SACL access rights, Object-specific access rights, user rights
Constant in Win32 API
Meaning
GENERIC_ALL
Read, write, and execute access
GENERIC_EXECUTE
Execute access
GENERIC_READ
Read access
GENERIC_WRITE
Write access
Constant in Win32 API
Meaning
DELETE
The right to delete the object.
READ_CONTROL
The right to read the information in the object's security descriptor, not including the information in the SACL.
SYNCHRONIZE
The right to use the object for synchronization. Some object types do not support this access right.
WRITE_DAC
The right to modify the DACL in the object's security descriptor.
WRITE_OWNER
The right to change the owner in the object's security descriptor.
SECURITY INNOVATION ©2003

42. Access Control: How does it Work? The Windows Model
SECURITY INNOVATION ©2003

43. Access Checking & Audit Generation
Function “AccessCheckAndAuditAlarm” determines whether the subject is allowed or denied access and then determines is there a need to generate an auditing entry in the security log.
It considers the following
Subjects access token
Subject’s desired access mask (a data structure 32 bit log, each bit corresponding to a particular access rights)
Object’s security descriptor
After the access-checking is complete, this function returns a granted access mask (it is identical to desired access mask except that all bits are initially turned off)
SECURITY INNOVATION ©2003

44. Auditing
Here, we generate entries in the security log for successful or failed attempts to access an object
After the access checking is over, the function will tell us what need to be logged in
Subject’s access token
Desired access mask – subject
Granted access mask – access check
Object’s SACL
SECURITY INNOVATION ©2003

45. Access Control - Strategies
TYPES:
Discretionary Access Control (DAC)
Roles-Based Access Control (RBAC)
Mandatory Access Control (MAC)
SECURITY INNOVATION ©2003

46. Access Control - Strategies
Discretionary access control:
Owner principle: owner decides about access control
Role-based access control:
Access rights depend on the roles of subjects
Mandatory access control:
System rules (MAC) decide about access
System rules govern owner principle
Examples: SE-VMS, Trusted Solaris
SECURITY INNOVATION ©2003

47. Discretionary Access Control (DAC)
Owner principle: owner decides about access control
Conditions:
There is a subject
There is an object
There are other users
DAC: “The subject (a) decides who among users (c) has what level of access on the object (b)”
SECURITY INNOVATION ©2003

48. Discretionary Access Control
Owner of an object can arbitrarily grant access rights to other subjects
Problem of how to limit propagation of rights
Granted access rights can be granted again to other subjects
Problem of Trojan horses
SECURITY INNOVATION ©2003

49. DAC and the Trojan Horse Scenario
Robert: read, write
Classified
Robert
Ivan: read, write
REJECTED!
Black is not allowed
To access Classified
Non Classified
Read Classified
Ivan
SECURITY INNOVATION ©2003

50. DAC and the Trojan Horse Scenario
Robert: read, write TH
Reads
Classified
Word Processor
Robert’s Classified
Robert
Uses shared program
Ivan, Robert: read, write TH
Copies
Classified
To Ivan’s
Directory
When Robert, a Secret user, runs programs, those programs (text editors, etc.) are able to access all files accessible by Alice, because those programs are running on behalf of Alice.
When Alice runs the compromised word processor program, it too runs on her behalf and can access all files accessible by Alice. Thus, the compromised word processor program can read all files readable by Alice and make a copies of them into Ivan’s directory with permissions on the files set such that they are readable by Ivan. The gist is, when Alice runs the compromised word processor program (or any malicious software) it can do any thing that Alice can do.
Robert’s Classified
Inserts Trojan Horse
Into shared program
Ivan
SECURITY INNOVATION ©2003

51. Discretionary Access Control
DAC mechanisms have an inherent weakness.
They are vulnerable to Trojan Horse attacks.
SECURITY INNOVATION ©2003

52. DAC Weakness How great is the threat of malicious software?
Consider the following points:
How much software on your own system did you write?
How much software on your system can you absolutely vouch for?
More and more software is written overseas these days.
It only takes one bad engineer in a group of a thousand good engineers to embed a Trojan Horse in a product.
If you store information that is worth stealing, the Trojan Horse attack is very attractive
Are you running a browser that downloads and executes Java applets?
SECURITY INNOVATION ©2003

53. DAC Weakness Want to know more?
A Guide to Understanding Discretionary Access Control in Trusted Systems, NCSC-TG-003
SECURITY INNOVATION ©2003

54. Role-Based Access Control (RBAC)
Access Based on Organizational Roles or Functions
Enforces Security Policies
Reduces Complexity & Cost
SECURITY INNOVATION ©2003

55. RBAC Mechanism Users are associated with roles.
Roles are associated with permissions.
A user has a permission only if the user has an authorized role which is associated with that permission.
SECURITY INNOVATION ©2003

56. Role-Based Access Control
Role-based security model is a tupel
RBAC = (S, O, RL, P, sr, pr, session)
Such that:
S is a set of users of a system
O is a set of objects
RL is set of roles
P is a set of access rights
sr (subject roles), pr (privileges), sess (sessions) are relations
SECURITY INNOVATION ©2003

57. Example: The Three Musketeers (User/Permission Association)
RBAC Mechanism
Example: The Three Musketeers
(User/Permission Association)
Athos
Aramis
palace
uniform
Porthos
D'Artagnan
weapons
SECURITY INNOVATION ©2003

58. RBAC Mechanism Athos Porthos Aramis D'Artagnan Athos Aramis Porthos
palace
Porthos
Musketeer
Aramis
uniform
D'Artagnan
weapons
Athos
Aramis
palace
uniform
Porthos
D'Artagnan
weapons
SECURITY INNOVATION ©2003

59. Example: (D’Artagnon becomes a Musketeer)
RBAC Mechanism
Example: (D’Artagnon becomes a Musketeer)
palace
D'Artagnan
Musketeer
uniform
weapons
palace
D'Artagnan
uniform
weapons
SECURITY INNOVATION ©2003

60. Role-Based Access Control
Roles (instead of persons) determine access rights
Subjects may have different roles according to their tasks
Example Trusted Solaris (root is divided into 4 roles)
Security officier, system admin, ...
Example Banking:
teller, account executive, manager, V.P., customer
SECURITY INNOVATION ©2003

61. RBAC Model Role Hierarchies, e.g, teller inherits employee
Conflict of Interest Constraints:
Static Separation of Duty: user cannot be authorized for both roles, e.g., teller and auditor
Dynamic Separation of Duty: user cannot act simultaneously in both roles, e.g., teller and account holder
Role Cardinality: maximum number of users authorized for role, e.g., branch manager
SECURITY INNOVATION ©2003

62. Banking Example: Hierarchy of Roles
Teller
V.P.
Customer
Employee
Account
executive
Manager
SECURITY INNOVATION ©2003

63. Role-Based Access Control Summary
Express organizational policies
Separation of duties
Delegation of authority
Flexible: easy to modify to meet new security requirements
Supports
Least-privilege
Data abstraction
RBAC is independent from DAC and MAC (they may coexist)
SECURITY INNOVATION ©2003

64. Mandatory Access Control (MAC)
Why Do We Need a MAC Policy?
We know that DAC policies inherently cannot prevent a malicious software (Trojan horse) attack. A policy is needed that can address the malicious software problem.
SECURITY INNOVATION ©2003

65. Mandatory Access Control (MAC)
A Mandatory Access Control policy is a policy in which people do not have control over the authorization of people to information.
Note how this policy differs from a DAC policy.
SECURITY INNOVATION ©2003

66. Mandatory Policies are ….
Global - sensitivity of information does not change relative to its "location" in the system
Persistent- sensitivity of information does not change with respect to time. For example, time does not state that information is TS on MWF but only C the remaining days of the week
SECURITY INNOVATION ©2003

67. Mandatory Access Control Policy Definitions
Access Class
User - Clearance
Information - Sensitivity
Clearance and Sensitivity can be mapped to system attributes call Access Classes.
Object
Any passive entity that contains information. It may be helpful to consider this as a file.
Subject
Active entities operating on behalf of users. It may be helpful to consider this as being associated with a process.
SECURITY INNOVATION ©2003

68. MAC Policy Implementation
Each subject has a label (or access class).
Each object has a label (or access class).
The ability of a subject to access an object is based upon a comparison of the subject’s label and the object’s label.
Two labels are compared using the "dominance" operator "≥". i.e., if label A dominates label B, we write A ≥ B.
Object labels and subject labels are a requirement of MAC policy implementations.
SECURITY INNOVATION ©2003

69. MAC Policy Implementation Example
As an example, consider the set of military classification levels
{Top Secret, Secret, Confidential, Unclassified}.
Where:
Top Secret ≥ Secret
Top Secret ≥ Confidential ≥
Top Secret ≥ Unclassified ≥
Secret ≥ Confidential ≥ etc.
Technically , Top Secret ≥ Top Secret. Secret ≥ Secret , etc.
SECURITY INNOVATION ©2003

70. Access Control is Defined by…
Policies
Access Control Methods
Access Matrix, Capabilities, Access Control Lists (ACLs)
Trusted Computing
Operating System Certification
SECURITY INNOVATION ©2003

71. Security Models Security Models Bell-LaPadula Biba Chinese Walls
Clark-Wilson
SECURITY INNOVATION ©2003

72. Bell and LaPadula Model (BLP)
David Bell and Len LaPadula, 1973 on initiative of US Air Force
The Bell and LaPadula Model is a mathematical description of a Security Policy
A state machine model written at MITRE, Bedford MA for the Multics operating system
Has been the most influential model of security over the past ~30 years.
The policy in the BLP model and some of the elements of the model are embedded within the TCSEC. It purports to implement the Department of Defense (DoD) security policy.
SECURITY INNOVATION ©2003

73. What is the TCSEC? The Trusted Computer System Evaluation Criteria
AKA “The Orange Book”
Written by the DoD to describe the security and assurance requirements necessary for government and military systems
Defined several “rating classes”, which were inclusive and increasing C2, B1, B2, B3, A1
Operating system centric
Used for 17 years as the de facto standard for trusted systems
Retired in 1999 in favor of a new criteria and methodology called the Common Criteria.
SECURITY INNOVATION ©2003

74. Bell and LaPadula Model
The Bell and LaPadula Model specifies read and write access between a subject and an object based upon the dominance relationship between the subject’s label (or access class) and the object’s label (or access class).
Core of operating system is the reference monitor (security kernel) that checks all accesses
SECURITY INNOVATION ©2003

75. Bell and LaPadula Model
The Bell and LaPadula Model is the most common model for MAC policies.      
Applies only to secrecy (not integrity) of information.
It includes both discretionary and mandatory access rules
Both checks are made upon request for access.
We will only look at the MAC aspects of the model since we are using the model to demonstrate a MAC policy.
SECURITY INNOVATION ©2003

76. BLP Mandatory Access Control
Lets S be the set of all subjects in a system and O be the set of all objects in a system.
For each subject s in S there exists a label or access class for s called C(s).
For each subject o in O there exists a label or access class for o called C(o).
SECURITY INNOVATION ©2003

77. Simple Security and Star Property
The Simple Security Property:   
The normal "no read up" policy where Secret users can read Secret, Confidential and Unclassified information (read down allowed) but
Secret users cannot read Top Secret (no read up)
Confinement property (the *-Property, pronounced ’Star Property’)
A subject has write access to an object only if classification of the object dominates the clearance of the subject. This is required to prevent malicious software from writing down.
Tranquility property
The classification of an object does not change while the object is being processed by the system.
Information cannot flow downward!
SECURITY INNOVATION ©2003

78. Why the *-Property is needed
Recall the shared word processor that contained a Trojan horse program. If a Secret user uses the program on a system that does not enforce the *-Property, the Trojan horse could read Secret files and write them to Unclassified files, where Ivan (the person who installed the Trojan and who is an Unclassified user) can read them.
If, however, a system enforces the *-Property, a Trojan horse cannot write down.
SECURITY INNOVATION ©2003

79. Mandatory Access Control
In a computer system, a mandatory policy can protect information in objects from unauthorized access even in the face of malicious software.
SECURITY INNOVATION ©2003

80. Summary of the BLP rules:
No read up and   No write down.
The BLP Model is often described in terms of secure information flows. The Figure below shows such a flow diagram. This is another way of saying that there is "no read up" and "no write down."
As indicated by the diagram on the next slide, a subject can only both read and write an object if the object has the same access class value as the subject.
SECURITY INNOVATION ©2003

81. Bell and LaPadula Model
High O5
Write
Write S2 O4
Read
Read O3
Write
Write S1 O2
Read
Subject Object
Read O1
Low
SECURITY INNOVATION ©2003

82. Bell and LaPadula Example
Consider the following objects and subjects:
File1 has an access class value of Secret.
File2 has an access class value of Confidential.
File3 has an access class value of Top Secret.   
Subject1 has an access class value of Top Secret.
Subject2 has an access class value of Confidential
SECURITY INNOVATION ©2003

83. Bell and LaPadula Example
Under the BLP Model the following accesses are allowed:
Subject1 can read File1, File2 and File3.
Subject1 can write only File3.
Subject2 can read File2.
Subject2 can write File1, File2 and File3.
SECURITY INNOVATION ©2003

84. Bell and LaPadula Can an Unclassified user blindly write to Secret?
Yes. The model allows it, but most implementations prohibit arbitrary blind write-ups.
SECURITY INNOVATION ©2003

85. Mandatory Access Control Issues
How does Alice, a Secret user, write information to an Unclassified file?
Remember we can only write up
The Notion of Sessions
SECURITY INNOVATION ©2003

86. Mandatory Access Control Issues
Systems that support MAC policies, must also support the notion of a session level.
When a user logs on they request a session level, which can be any level up to their clearance level.
If Alice logs on and requests a session level of Secret, a Secret level subject is created on her behalf. This subject can read files at or below Secret and can write files at or above Secret.
While Alice is logged in, she can re-negotiate a new session level to any other level that she is allowed to operate at. This means if she needs to write an unclassified file, she must negotiate an unclassified session.
Session negotiation should use the trusted path
SECURITY INNOVATION ©2003

87. Bell and LaPadula Nowhere!
Where does data integrity fit into a Mandatory Access Control scheme that enforces the BLP Model?
Nowhere!
SECURITY INNOVATION ©2003

88. Integrity
The term integrity is used in two ways in the context of computer security.
Program or execution integrity refers to a system’s ability to provide protected domains of execution.
Data integrity refers to keeping data free from unauthorized modification
SECURITY INNOVATION ©2003

89. Secrecy versus Integrity
Secrecy and data integrity concerns are distinct.
Secrecy concerns the prevention of unauthorized disclosure of data or information.
The Golden Triangle of COMPUSEC
Secrecy
Integrity
Availability
SECURITY INNOVATION ©2003

90. Biba Integrity Model
In addition to enforcing a policy for secrecy, we would like systems to enforce a mandatory policy for data integrity too.
The Biba Integrity Model addresses the unauthorized modification problem by restricting read and write accesses.
Uses integrity levels and integrity compartments much like sensitivity levels and sensitivity compartments
SECURITY INNOVATION ©2003

91. Biba Integrity Model Focus on integrity
Assurance of integrity requires that data not flow from a receptacle of lower integrity to a receptacle of higher integrity
If a process can write above its security level, trustworthy data could be contaminated by the addition of less trustworthy data
Biba rules:
No write up.
No read down.
SECURITY INNOVATION ©2003

92. Chinese-Wall Model (Bresher-Nash)
Drives commercial Security policies and is oriented towards confidentially.
Previous actions of a subject determines (i.e. restricts) access rights i.e. rights are continually decreasing
Rights are usually read, write, execute
Read-Access:
Only if no previous access to another object of the same conflict class but different company
Conflict classes’ – group of competitive companies
Write-Access:
Only if all previous read-accesses are concerned with objects of the same company.
Protects ‘leaking’ of information
SECURITY INNOVATION ©2003

93. Clark-Wilson Model
Earlier models emphasized the government approach of confidentiality.
The commercial approach is more concerned with integrity
As opposed to subject/object pairs as earlier lattice models used, C-W model uses subject/program/model triples
Characterized by well-formed’ transactions:
Exact order of known actions
Authentication of user performing actions
SECURITY INNOVATION ©2003

94. Clark-Wilson Model Addresses all 3 integrity goals
Prevents unauthorized users from making modifications
Maintains internal and external consistency
Prevents authorized users from making improper modifications
Files cannot be tampered with while being changed
All changes must be logged
Integrity of data is consistent
SECURITY INNOVATION ©2003

95. Mandatory Access Control Conclusions
A MAC policy can prevent malicious software (e.g., Trojan horses) from directly leaking information from high to low.
Recall that we trust users to not give the store away, but we generally can’t say the same thing for software.
So we build systems that enforce a MAC policy on applications and we don’t have to worry about the application software.
For example, a subject running at Secret cannot write any information at a level below Secret.
SECURITY INNOVATION ©2003

96. Trojan horse can write between objects at the same level.
For example, a Trojan horse can read one Secret file and copy it to another Secret file.
Is this a problem?
SECURITY INNOVATION ©2003

97. Mandatory Access Control and the Trojan Horse Scenario
This scenario would require a bad guy (e.g., Ivan) to have a Secret clearance. (The reason why personnel security is important.)
He installs a Trojan horse into a shared word processor program.  
Sue, a Secret user, uses the word processor and the Trojan horse copies her Secret files into John’s directory. But John is already cleared for Secret information so the Trojan horse does not get him any information he is not already cleared to see.
In general, systems that support a MAC policy also support a DAC policy to provide a convenient separation of user’s data.
SECURITY INNOVATION ©2003

98. A Potential Problem with the Mandatory Access Control Approach
Covert Channels can still leak information from high to low in spite of a MAC policy.
SECURITY INNOVATION ©2003

99. Covert Channels
Covert channels are flows of information between access class levels counter to a MAC policy but which are allowed by an implementation.
Covert channels are a means of leaking information from high to low, one bit at a time.     
If the rate of transmitting bits across the channel (the channel baud rate) is great, this threat is significant.
SECURITY INNOVATION ©2003

100. Covert Channels
Covert channels involve two programs, of which one must be a Trojan horse.
Covert channels are a little complicated to implement.
However, if information being stored is very valuable, the covert channel threat is real.
SECURITY INNOVATION ©2003

101. Covert Channels-Storage
Covert storage channels exploit a resource common to both a high subject and a low subject.
Automated flow analysis tools can identify every storage channel in a formal specification of a system’s interface.
SECURITY INNOVATION ©2003

102. Covert Channels-Timing
Covert timing channels exploit a mechanism where a high subject can affect the timing of low subject.
No automatic means exist for identifying every existing timing channel at a system’s interface.
Timing channels are identified by a examination of the interface.
SECURITY INNOVATION ©2003

103. Covert Channels-Example
The classic example of a covert storage channel is the disk exhaustion channel.
Step 1
Ivan, (a low user) introduces a Trojan horse program (e.g., Star Trek game) into the system and somehow gets a high user to execute it.
When the high user plays the Star Trek game a sub-program is spawned and goes to sleep. The sub-program contains the Trojan horse and wakes up and starts running at a time when activity on the system is low (e.g., at 0100).
SECURITY INNOVATION ©2003

104. Covert Channels Step 2
John starts another program (a low program) that will wake up at 0105, (5 minutes later than the high program). This allows the high program time to initialize the channel.
The high program finds a high file to copy (fileA).
The high program initializes the channel by repeatedly creating files until the "disk full" exception is returned.
The two programs will synchronize with each other by reading a system clock. The high program will signal bits on every even millisecond and the low program will receive bits on every odd millisecond.
SECURITY INNOVATION ©2003

105. Covert Channels Step 3
The high program starts reading the bits out of FileA. The following steps are repeatedly performed until the high program is through reading the file.
The high program does: (on even milliseconds)
If a bit is a 0, the high program deletes one file. (Creating room on the disk for a file to be created.)
If a bit is a 1, the high program does not delete a file. (So there is no room on the disk to create a file).        
The low program does: (on odd milliseconds)
The low program always tries to create a file. If there is room on the disk, the create file call is successful.
If the call is successful, the low program writes a 0 into a destination file.
If there is no room on the disk, the create file call will fail, with the "disk full" exception. If the call is unsuccessful, the low program writes a 1 into the destination file.
SECURITY INNOVATION ©2003

106. Storage Channel Example Conclusions:
The channel baud rate of the previous example is 1 bit every 2 milliseconds.
This is 500 bits per second, which is 30,000 bits per minute.
The timing scheme used in the example is very conservative. Much higher baud rates are generally attainable.
SECURITY INNOVATION ©2003

107. Covert Channels Countermeasure
One way to close the disk exhaustion channel is to partition the disk into volumes and allocate each volume to a different security level. For example, volume 0 is for TS files, volume 1 is for S files and volume 2 is for C files.
Under this partitioning scheme, a C subject cannot tell if the TS volume is full or not. Recall that in the covert channel scenario, the C subject determined if the disk was full by attempting to create a file. Under the partitioning scheme, C subjects create files on a separate volume than the TS subjects.
SECURITY INNOVATION ©2003

108. Covert Timing Channels
Covert timing channels exploit a mechanism where a high subject can affect the timing of a low subject.
A potential timing channel, which exists on single processor systems, uses the fact that both the high subject and the low subject use the same physical processor.
To signal a 1, the high subject performs a lengthy operation (e.g., disk I/O) and signals a 0 by performing a short operation.
When the high subject finishes its operation, the low subject is scheduled to run.
When the low subject gets scheduled, it reads the system clock and determines how long the high subject operation took.
Clark, D.R. and Wilson, D.R., A Comparison of Commercial and Military Computer Security Policies, Proceedings of the 1987 IEEE Symposium on Security and Privacy, pages , 1987
ESORICS 2000 (Springer Lecture Notes in Computer Science 1895): Checking secure interactions of Smart Card Applets and Verification of a Formal Security Model for Multiapplicative Smart Cards
Bell, D. and LaPadula, L., MITRE Technical Report 2547 (Secure Computer System): Volume II, Journal of Computer Security, vol. 4, no. 2/3, pages , 1996
Goguen, J.A. and Meseguer, J., Security Policies and Security Models, Proceedings of the 1982 IEEE Symposium on Security and Privacy, pages 11-20, 1982
(IBM technical report on Multics)
SECURITY INNOVATION ©2003