Bài giảng Information Systems Security - Chapter 2: Introduction to DAC
DAC & INFORMATION FLOW CONTROLS
Inherent weakness of DAC: Unrestricted DAC allows
information from an object which can be read by a subject to
be written to any other object
Bob is denied access to file A, so he asks cohort Alice to copy
A to B that he can access
Suppose our users are trusted not to do this deliberately. It is
still possible for Trojan Horses to copy information from one
object to another.
40 trang |
Chia sẻ: vutrong32 | Lượt xem: 1140 | Lượt tải: 0
Bạn đang xem trước 20 trang tài liệu Bài giảng Information Systems Security - Chapter 2: Introduction to DAC, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
DISCRETIONARY ACCESS CONTROL
Tran Thi Que Nguyet
Faculty of Computer Science & Engineering
HCMC University of Technology
ttqnguyet@cse.hcmut.edu.vn
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
2
Outline
2
Introduction to Discretionary Access Control1
Propose Models for DAC2
SQL for Data Control3
DAC & Information Flow Controls4
Homework: Case study in SQL Server 2008 – Reading chapter 4 – Access
control for Databases: Concepts and Systems. Elisa Bertino, et al.
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
3
Introduction to DAC
Discretionary Access Control (DAC):
User can protect what they own.
The owner is given all privileges on their own data.
The owner can define the type of access
(read/write/execute/) and grant access to others.
The typical method of enforcing DAC in a database system is
based on the granting and revoking privileges
3
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
4
Introduction to DAC
Types of Discretionary Privileges:
The account/system level: The administrator specifies the
particular privileges that each account holds independently of
the objects in the database system.
The object level: The administrator can control the privilege
to access each individual object in the database system.
4
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
5
Introduction to DAC
The account/system level privileges (example)
CREATE SCHEMA
CREATE TABLE
CREATE VIEW
ALTER
DROP
MODIFY
SELECT
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
6
Introduction to DAC
The object level privileges
Data objects: relation or view
Includes:
INSERT
UPDATE
DELETE
DELETE
REFERENCE
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
7
Outline
7
Introduction to Discretionary Access Control1
Propose Models for DAC2
SQL for Data Control3
DAC & Information Flow Controls4
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
8
Proposed Models for DAC
General definition: security model
Access matrix model
Take-Grant model
8
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
9
Security model
A security model provides a semantically rich representation in
that it allows functional and structural properties of the security
system to be described.
A security model describes the protection needs of the system.
It is a high-level, software-independent, conceptual model.
Types of security model
Discretionary model:
DAC model govern access of users to the information on the basis of
the users’ identity and of rules that specify, for each user and object in
the system, the types of access the user is allowed for the object.
The request of a user to access an object is checked against the
specified authorizations.
Non-discretionary model
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
10
Access matrix model
An access matrix is a matrix correlating the subjects, objects and the
authorizations owned by each subject on each object.
Authorization state: Q=(S,O,A)
S (Subjects): a set of subjects or active entities that use system
resources.
Ex: user, group, process
O (Objects): a set of passive objects which must be protected such as
subjects and system resources
Ex: OS level: file, memory, segments, process.
DB level: database, relation, attribute, record, field
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
11
Access matrix model
Authorization state: Q=(S,O,A)
A: Access matrix
Row: subjects
Column: objects
A[s,o]: access mode
For DBs, A[s,o] also includes
conditions that must be satisfied
in order for s to exercise the
access modes
Possible conditions: data-dependent
(sal<1000), time-dependent (8:00am-
5:00pm), context-dependent (“name-
salary” pair is prohibited), history-
dependent,
O1 Oi Om
S1
A[s1,o
1]
A[s1,o
i]
A[s1,om
]
Si A[si,o1]
A[si,oi
]
A[si,om]
Sn
A[sn,o
1]
A[sn,o
i]
A[sn,om
]
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
12
Access matrix model
Asset 1 Asset 2 file device
Role 1
read,
write,
execute,
own
execute read write
Role 2 read
read,
write,
execute,
own
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
13
Access matrix model
Model implementation:
S {(O,A)}: capability list
Alice {(file X, {read, delete}), (file Y, {update})}
O{(S,A)}: ACL (access control list)
File X {(Alice, {read, delete}), (Bob, {read})}
Each entry in the list specifies a subject and operation(s): for
example, the entry (Alice, delete) on the ACL for file X gives
Alice permission to delete file X
Advantages & disadvantages of the two above & the model?
Capability list: compute a set of subjects granted access on a
given object all lists must be gone through
ACL: find all objects a subject can access
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
14
(a)
(b) CL
(c) ACL
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
15
Take-Grant model
Authorization state: G=(S,O,E)
V=S U O is the set of vertexes, S ∩ O = Ф
E is the set of labelled arcs
take(d,s,x,y): the subject s takes the right d on the
object/subject y from the object/subject x
15
t
s
y
x
d
t
s
y
x
ddtake(d,s,x,y)
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
16
Take-Grant model
16
g
s
y
x
d
g
s
y
x
ddgrant(d,s,x,y)
• grant(d,s,x,y): the subject s grants the right d on the
object/subject y to the object/subject x
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
17
Take-Grant model
Access modes: read, write, take, grant
Read, write: inert rights
Take, grant: transport rights
Other rights
Create(s, x): subject s creates object x (The arc is labelled with
p, possess)
removep(s, x): The possess right p on a subject/an object x is
removed from a subject s.
This model is classifiable as an access matrix model
Disadvantages?
17
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
18
Take-Grant model
Disadvantages:
Non-selectivity of administrative rights: all authorizations of S
owning a ‘GRANT’ authorization can be transferred, and all
authorizations of O/S on which a ‘TAKE’ right is held can be
taken
No control on propagation of authorizations
Non locality: S owning the grant privilege on O can give any
of its privileges to O, thus augmenting the domain of O (the
set of authorizations associated to O)
Reversibility of the privileges transport flow
18
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
19
Other models
Acten (Action-Entity) model
Wood et al. model
See [S. Castano, M. Fugini, G. Martella, and P. Samarati (1995). Database
Security, ACM Press & Addison-Wesley, ISBN 0-201-59375-0] + Internet
19
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
20
Outline
20
Introduction to Discretionary Access Control1
Propose Models for DAC2
SQL for Data Control3
DAC & Information Flow Controls4
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
21
SQL for Data Control
Commands:
• GRANT
• REVOKE
Based on three central objects:
• Users
• Database objects
• Privileges: select, modify (insert, update, delete), reference
21
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
22
SQL for Data Control
GRANT: pass privileges on their own database objects to
other users
GRANT
ON
TO
REVOKE: take back (cancel) privileges on their own
database objects from other users
REVOKE
ON
FROM
22
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
23
SQL for Data Control
Propagation of Privileges using the GRANT OPTION
Whenever the owner A of a relation R grants a privilege on R
to another account B, privilege can be given to B with or
without the GRANT OPTION.
If the GRANT OPTION is given, this means that B can also
grant that privilege on R to other accounts.
23
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
24
Limit horizontal propagation
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
25
Limit Vertical Propagation
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
26
Revocation of authorization
(b) B revokes D’s privilege (cascade)
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
27
SQL for Data Control
DAC with views (virtual relations)
If the owner A of a relation R wants another account B to be able to
retrieve only some fields of R, then A can create a view V of R that
includes only those attributes and then grant SELECT on V to B.
The same applies to limiting B to retrieving only certain tuples of R;
a view V’ can be created by defining the view by means of a query
that selects only those tuples from R that A wants to allow B to
access.
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
28
An Example
Suppose that the DBA creates four accounts
A1, A2, A3, A4
and wants only A1 to be able to create base relations. Then
the DBA must issue the following GRANT command in
SQL
GRANT CREATETAB TO A1;
In SQL2 the same effect can be accomplished by having the
DBA issue a CREATE SCHEMA command as follows:
CREATE SCHEMA EXAMPLE AUTHORIZATION A1;
28
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
29
An Example(2)
User account A1 can create tables under the schema called
EXAMPLE.
Suppose that A1 creates the two base relations
EMPLOYEE and DEPARTMENT
A1 is then owner of these two relations and hence all the relation
privileges on each of them.
Suppose that A1 wants to grant A2 the privilege to insert and
delete tuples in both of these relations, but A1 does not want
A2 to be able to propagate these privileges to additional
accounts:
GRANT INSERT, DELETE ON
EMPLOYEE, DEPARTMENT TO A2;
29
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
30
An Example(3)
30
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
31
An Example(4)
Suppose that A1 wants to allow A3 to retrieve information
from either of the two tables and also to be able to propagate
the SELECT privilege to other accounts.
A1 can issue the command:
GRANT SELECT ON EMPLOYEE, DEPARTMENT
TO A3 WITH GRANT OPTION;
A3 can grant the SELECT privilege on the EMPLOYEE
relation to A4 by issuing:
GRANT SELECT ON EMPLOYEE TO A4;
Notice that A4 can’t propagate the SELECT privilege because
GRANT OPTION was not given to A4
31
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
32
An Example(5)
Suppose that A1 decides to revoke the SELECT privilege on
the EMPLOYEE relation from A3; A1 can issue:
REVOKE SELECT ON EMPLOYEE FROM A3;
The DBMS must now automatically revoke the SELECT
privilege on EMPLOYEE from A4, too, because A3 granted
that privilege to A4 and A3 does not have the privilege any
more.
32
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
33
An Example(6)
Suppose that A1 wants to give back to A3 a limited capability to
SELECT from the EMPLOYEE relation and wants to allow A3 to be
able to propagate the privilege.
The limitation is to retrieve only the NAME, BDATE, and ADDRESS
attributes and only for the tuples with DNO=5.
A1 then create the view:
CREATE VIEW A3EMPLOYEE AS
SELECT NAME, BDATE, ADDRESS
FROM EMPLOYEE
WHERE DNO = 5;
After the view is created, A1 can grant SELECT on the view
A3EMPLOYEE to A3 as follows:
GRANT SELECT ON A3EMPLOYEE TO A3
WITH GRANT OPTION;
33
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
34
An Example(7)
Finally, suppose that A1 wants to allow A4 to update only
the SALARY attribute of EMPLOYEE;
A1 can issue:
GRANT UPDATE ON EMPLOYEE (SALARY) TO A4;
The UPDATE or INSERT privilege can specify particular
attributes that may be updated or inserted in a relation.
Other privileges (SELECT, DELETE) are not attribute specific.
34
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
35
Outline
35
Introduction to Discretionary Access Control1
Propose Models for DAC2
SQL for Data Control3
DAC & Information Flow Controls4
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
36
DAC & INFORMATION FLOW CONTROLS
Inherent weakness of DAC: Unrestricted DAC allows
information from an object which can be read by a subject to
be written to any other object
Bob is denied access to file A, so he asks cohort Alice to copy
A to B that he can access
Suppose our users are trusted not to do this deliberately. It is
still possible for Trojan Horses to copy information from one
object to another.
36
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
37
Trojan horse Example
37
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
38
Trojan horse Example
38
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
39
Trojan horse Example
39
Ho Chi Minh City University of Technology
Faculty of Computer Science and Engineering
© 2011
Information Systems Security
Chapter 2: Introduction to DAC
40
40
Các file đính kèm theo tài liệu này:
- security_in_information_systems_2_introduction_to_dac_0781.pdf