Tải bản đầy đủ (.pptx) (58 trang)

Bài giảng Bảo mật cơ sở dữ liệu: Chapter 3 - Trần Thị Kim Chi

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (318.12 KB, 58 trang )

Chapter 3

Access Control
Discretionary Access Control


Agenda

1.
2.

Access Control
Discretionary Access Control


Access Control
“Access control” is where security engineering meets computer science.
Its function is to control which (active) subject have access to a which (passive) object with some
specific access operation.

subject

Access

Reference

request

monitor

object




Access Control
Determine whether a principal can perform a requested operation on a target object





Principal: user, process, etc.
Operation: read, write, etc.
Object: file, tuple, etc.

Lampson defined the familiar access matrix and its two interpretations ACLs and capabilities
[Lampson70]


Why are we still talking about access control?
An access control policy is a specification for an access decision function
The policy aims to achieve




Permit the principal’s intended function (availability)
Ensure security properties are met (integrity, confidentiality)





Limit to “Least Privilege,” Protect system integrity, Prevent unauthorized leakage, etc.
Also known as ‘constraints’

Enable administration of a changeable system (simplicity)


Example: Access Control
Prof Alice manages access to course objects
‣ Assign access to individual (principal: Bob)
‣ Assign access to aggregate (course-students)
‣ Associate access to relation (students(course))
‣ Assign students to project groups (student(course, project, group))
Prof Alice wants certain guarantees
‣ Students cannot modify objects written by Prof Alice
‣ Students cannot read/modify objects of other groups
Prof Alice must be able to maintain access policy
‣ Ensure that individual rights do not violate guarantees
‣ However, exceptions are possible – students may distribute their results from previous assignments for
an exam


Access Control is Hard Because
Access control requirements are domain-specific



Generic approaches over-generalize

Access control requirements can change




Anyone could be an administrator

The Safety Problem [HRU76]



Can only know what is leaked right now

Access is fail-safe, but Constraints are not



And constraints must restrict all future states


Safety Problem
Determine if an unauthorized permission is leaked given




An initial set of permissions and
An access control system, mainly administrative operations

For a traditional approach, the safety problem is undecidable






Access matrix model with multi-operational commands
Main culprit is create – create object/subject with own rights
Prove reduction of a Turing machine to the multi-operational access matrix system


Safety Problem
Result led to
Safe, but limited models: take-grant, schematic protection model, typed access matrix model
Further support for models in which the constraints are implicit in the model



e.g., lattice models

Check safety on each policy change – constraint approach of RBAC


Compare to Other CS Problems
Processor design



Hard, but can get some smart people together to construct one, fixed, testable design

Network protocol design




TCP: A small number of control parameters necessary to manage all reasonable options, within a layered

architecture



Constraints, such as DDoS, are ad hoc

Software design



Specific goals in mind to achieve function, constraints are ad hoc


Access Control Models
Discretionary Access Matrix



UNIX, ACL, various capability systems

Mandatory (Usually) Access Matrix



TE, RBAC, groups and attributes, parameterized

Plus Transitions




DTE, SELinux, Java

Lattice Access Control Models



Bell-LaPadula, Biba, Denning

Predicate Models



ASL, OASIS, domain-specific models, many others

Safety Models



Take-grant, Schematic Protection Model, Typed Access Matrix


Administration
Discretionary Access Control



Users (typically object owner) can decide permission assignments


Mandatory Access Control



System administrator decides on permission assignments

Flexible Administrative Management



Access control models can be used to express administrative privileges


Type Enforcement [BoebertKain84]


Group and Attributes


Access Control
Discretionary Access Control

– Access Matrix Model
– Implementation of the Access Matrix
– Vulnerabilities of the Discretionary Policies
– Additional features of DAC


Discretionary Access Control



Discretionary Access Control is an individual user can set an access control mechanism to allow
or deny access to an object.





Relies on the object owner to control access.
DAC is widely implemented in most operating systems, and we are quite familiar with it.
Strength of DAC: Flexibility: a key reason why it is widely known and implemented in
mainstream operating systems.


Discretionary Access Control


Access to data objects (files, directories, etc.) is permitted based on the identity of
users.



Explicit access rules that establish who can, or cannot, execute which actions on
which resources.



Discretionary: users can be given the ability of passing on their privileges to other
users, where granting and revocation of privileges is regulated by an administrative
policy.



Discretionary Access Control

 DAC is flexible in terms of policy specification
 This is the form of access control widely implemented in standard multi-user platforms
Unix, NT, Novell, etc.


Limitation of DAC
Global policy: DAC let users to decide the access control policies on their data, regardless of whether those
policies are consistent with the global policies. Therefore, if there is a global policy, DAC has trouble to ensure
consistency.
Information flow: information can be copied from one object to another, so access to a copy is possible even if
the owner of the original does not provide access to the riginal copy. This has been a major concern for military.
Malicious software: DAC policies can be easily changed by owner, so a malicious program (e.g.,a downloaded
untrustworthy program) running by the owner can change DAC policies on behalf of the owner.
Flawed software: Similarly to the previous item, flawed software can be “instructed” by attackers to change its
DAC policies.


Discretionary Access Control

Access control matrix

– Describes protection state precisely
– Matrix describing rights of subjects
– State transitions change elements of matrix
State of protection system


– Describes current settings, values of system relevant to protection


Access Control
Discretionary Access Control

– Access Control Matrix Model
– Implementation of the Access Matrix
– Vulnerabilities of the Discretionary Policies
– Additional features of DAC


Access Control Matrix Model
Access control matrix





Firstly identify the objects, subjects and actions.
Describes the protection state of a system.
State of the system is defined by a triple (S, O, A)







S is the set of subject,

O is the set of objects,
A is the access matrix

Elements indicate the access rights that subjects have on objects



Entry A[s, o] of access control matrix is the privilege of s on o


Description
objects (entities)
o1

subjects

s1
s2



sn

… om s1 … sn

Subjects S = { s1,…,sn }
Objects O = { o1,…,om }
Rights R = { r1,…,rk }
Entries A[si, oj] ⊆ R
A[si, oj] = { rx, …, ry } means subject si

has rights rx, …, ry over object oj


Boolean Expression Evaluation
ACM controls access to database fields

– Subjects have attributes
– Action/Operation/Verb define type of access
– Rules associated with objects, action pair
Subject attempts to access object

– Rule for object, action evaluated, grants or denies access


Example
Subject Annie



Attributes role (artist), groups (creative)

Verb paint



Default 0 (deny unless explicitly granted)

Object picture




Rule:
Annie paint picture if:
‘artist’ in subject.role and
‘creative’ in subject.groups and
time.hour ≥ 0 and time.hour < 5


×