Security in Information Systems: Chapter 2 - Discretionary access control

Security in Information Systems: Chapter 2 - Discretionary access control Introduction to Discretionary Access Control, Propose Models for DAC, SQL for Data Control, DAC & Information Flow Controls.

DISCRETIONARY ACCESS CONTROL

Tran Thi Que Nguyet Faculty of Computer Science & Engineering

HCMC University of Technology ttqnguyet@cse.hcmut.edu.vn

Homework: Case study in SQL Server 2008 – Reading chapter 4 – Access

control for Databases: Concepts and Systems Elisa Bertino, et al

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

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.

Introduction to DAC

 The object level privileges

 Data objects: relation or view

Proposed Models for DAC

 General definition: security model

 Access matrix model

 Take-Grant model

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

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

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

A[s1,om ]

A[sn,om ]

Access matrix model

Role 1

read, write, execute, own

read, write, execute, own

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

(a) <S i , O j , A[S i , O j ]>

(b) CL

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 d d

take(d,s,x,y)

Take-Grant model

g s

y

x

d

g s

y

x

d d

grant(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

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)

 remove p (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

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

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

SQL for Data Control

SQL for Data Control

 GRANT: pass privileges on their own database objects to

other users

GRANT <privilege list>

ON <database objects>

TO <user list>

 REVOKE: take back (cancel) privileges on their own

database objects from other users

REVOKE <privilege list>

ON <database objects>

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

Limit horizontal propagation

Limit Vertical Propagation

Revocation of authorization

 (b) B revokes D’s privilege (cascade)

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.

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;

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

An Example(3)

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;

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

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.

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

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.

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.

Trojan horse Example

37

Trojan horse Example

Trojan horse Example

39