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

Bài giảng Bảo mật cơ sở dữ liệu - Chương 3: Bảo mật theo cơ chế MAC cung cấp cho người học các kiến thức: Define Mandatory Access Control Models, secrecy-preserving models, integrity-preserving models, multi-Level security, multi-level databases access control models,... Mời các bạn cùng tham khảo.

Bảo mật theo cơ chế MAC

Mandatory Access Control Models

5 Multi-level databases access control models

6 Multi-level secure DBMS architecture

7 MAC trong các hệ QTCSDL thông dụng

Define Mandatory Access Control

Mandatory Access Control : A system-wide policy decrees who is allowed to have access; individual user cannot alter that access.

Relies on the system to control access.

Examples:

– The law allows a court to access driving records

without the owners’ permission

Traditional MAC mechanisms have been tightly coupled to a few security models.

Recently, systems supporting flexible security

models start to appear (e.g., SELinux, Trusted

Solaris, TrustedBSD, etc.)

Mandatory Access Control vs Discretionary

Access Control

MAC is centrally controlled by a security policy

administrator; users do not have the ability to override the policy and, for example, grant access to files that would otherwise be restricted

DAC, which also governs the ability of subjects to access objects, allows users the ability to make policy decisions and/or assign security attributes

MAC-enabled systems allow policy administrators to

implement organization-wide security policies

With DAC, users cannot override or modify this policy, either accidentally or intentionally This allows security administrators to define a central policy that is guaranteed (in principle) to be enforced for all users

Degrees of MAC system strength

In some systems, users have the authority to decide whether

to grant access to any other user To allow that, all users

have clearances for all data This is not necessarily true of a MAC system If individuals or processes exist that may be denied access to any of the data in the system environment, then the system must be trusted to enforce MAC Since

there can be various levels of data classification and user clearances, this implies a quantified scale for robustness For example, more robustness is indicated for system

environments containing classified Top Secret information and uncleared users than for one with Secret information and users cleared to at least Confidential To promote

consistency and eliminate subjectivity in degrees of

robustness, an extensive scientific analysis and risk

assessment of the topic produced a landmark benchmark standardization quantifying security robustness capabilities

of systems and mapping them to the degrees of trust

warranted for various security environments The result was documented in CSC-STD-004-85.[6] Two relatively

independent components of robustness were defined:

Assurance Level and Functionality Both were specified

with a degree of precision that warranted significant

confidence in certifications based on these criteria

Evaluation of MAC system strength

The Common Criteria[7] is based on this science and it

intended to preserve the Assurance Level as EAL levels and the functionality specifications as Protection Profiles Of these two essential components of objective robustness

benchmarks, only EAL levels were faithfully preserved In one case, TCSEC level C2[8] (not a MAC capable category) was fairly faithfully preserved in the Common Criteria, as the Controlled Access Protection Profile (CAPP).[9] 

Multilevel security (MLS) Protection Profiles (such as

MLSOSPP similar to B2)[10] is more general than B2 They are pursuant to MLS, but lack the detailed implementation requirements of their Orange Book predecessors, focusing more on objectives This gives certifiers more subjective

flexibility in deciding whether the evaluated product’s

technical features adequately achieve the objective,

potentially eroding consistency of evaluated products and making it easier to attain certification for less trustworthy products For these reasons, the importance of the technical details of the Protection Profile is critical to determining the suitability of a product

Such an architecture prevents an authenticated user or

process at a specific classification or trust-level from

accessing information, processes, or devices in a different level This provides a containment mechanism of users and processes, both known and unknown (an unknown program (for example) might comprise an untrusted application

where the system should monitor and/or control accesses to devices and files)

Definition and need for MLS

Multilevel security involves a database in which

the data stored has an associated classification

and consequently constraints for their access

MLS allows users with different classification levels to get different views from the same data MLS cannot allow downward leaking , meaning that a user with a lower classification views data stored with a higher classification

Definition and need for MLS

Usually multilevel systems are with the federal

government

Some private systems also have multilevel security

needs

MLS relation is split into several single-level relations,

A recovery algorithm reconstructs the MLS relation from the decomposed single-level relations

At times MLS updates cannot be completed because it would result in leakage or destruction of secret

information

Definition and need for MLS

In relational model, relations are tables and relations consist of tuples (rows) and attributes (columns)

Example :

Consider the relation

SOD(Starship, Objective, Destination)

Enterprise

Voyager

Exploration Spying

Talos Mars

Definition and need for MLS

The relation in the example has no

classification associated with it in a

relational model

The same example in MLS with

classification will be as follows:

Enterprise U

Voyager U

Exploration U Spying S

Talos U Mars S

Definition and need for MLS

In MLS, access classes can be assigned to:

– Individual tuple in a relation

– Individual attribute of a relation

– Individual data element of tuples in a relation

Bell – LaPadula Model

Biba Model

Bell – LaPadula Model

Proposed by David Bell and Len Lapadula in

1973, in response to U.S Air Force concerns over the security of time-sharing mainframe systems.

This model is the most widely recognized Access Matrix model with classified data

The model deal with confidentiality only.

This model has two components:

– Classification

– Set of categories

Bell-LaPadula model shows how to use Mandatory Access Control to prevent the Trojan Horse

Bell – LaPadula Model

Two properties: No read up and No write down.

Simple security property: Subject A is allowed to

read object O only if class(O) class(A).

*-property: Subject A is allowed to write object

O only if class(A) class(O).

The *-property was Bell and LaPadula’s critical innovation It was driven by the fear that a user with “Secret” clearance might be “tricked” by

attackers (e.g., through Trojan horse programs or software vulnerabilities) to copy down the

information to a ”Unclassified” area where the

attackers can read.

Bell – LaPadula Model

Example: In USA, a “SECRET” clearance

involves checking FBI fingerprint files

 Classification has four values {U, C, S, TS}

 U = unclassified

 C = confidential

 S = secret

 TS = top secret

 Classifications are ordered: TS > S > C > U

 Set of categories consists of the data environment and the application area, i.e., Nuclear, Army, Financial,

Research

Bell – LaPadula Model

An access class c1 dominates ≥ an access class

c2 iff

– Security level of c1 is greater than or equal to that of c2

– The categories of c1 include those of c2

Bell – LaPadula Model

Bell-LaPadula model is based on a object paradigm

subject-Subjects are active elements of the system that execute actions

Objects are passive elements of the system that contain information

Subjects act on behalf of users who have a security level associated with them (indicating the level of system trust)

Bell – LaPadula Model

Subjects execute access modes on objects Access modes are:

– Read-only

– Append (writing without reading)

– Execute

– Read-write (writing known data)

Decentralized administration of privileges

on objects

Bell – LaPadula Model

Control direct and indirect flows of information

Prevent leakage to unauthorized subjects

User can connect to the system with any access class dominated by their clearance

Two Principles

To protect information confidentiality

– No-read-up , a subject is allowed a read access

to an object only if the access class of the subject dominate the access class of the object

– No-write-down , a subject is allowed a write access to an object only if the access class of the subject is dominated by the access class of the object

No-read-up & No-write-down

 Can TS subject write to S object?

 Can S subject write to U object?

Solution to Trojan Horse

Possible classification reflecting the access

restrictions:

– Secret for Vicky and “Market”

– Unclassified to John and “Stolen”

If Vicky connect to system as secret, write is

Applying BLP: An Example

Alice has (Secret, {NUC, EUR}) clearance

David has (Secret, {EUR}) clearance

– David can talk to Alice (“write up” or “read down”)– Alice cannot talk to David (“read up” or “write down”)

Alice is a user, and she can login with a different

ID (as a different principle) with reduced

clearance

– Alias1 (Secret, {NUC, EUR})

– Alias2 (Secret, {EUR})

BLP: Problem

If I can write up, then how about writing files with blanks?

– Blind writing up may cause integrity

problems, but not a confidentiality breach

Bell – LaPadula Model

Two main properties of this model for a

secure system are:

– Simple security property

– Star property

Simple security means: A subject may have

read or write access to an object only if the clearance of the subject dominates the

security level of the object

Bell – LaPadula Model

Star property means: An untrusted subject may:

append if object security dominates subject security write if object security equals subject security

read if object security is less than subject security

This model guarantees secrecy by

preventing unauthorized release of

information

This model does not protect from

unauthorized modification of information

Key Points

Confidentiality models restrict flow of information Bell-LaPadula (BLP) models multilevel security

Cornerstone of much work in computer security

– Simple security property says no read up and

– Star property says no write down

– Both ensure information can only flow up

The Biba Model

A model due to Ken Biba which is often referred to as

“Bell-LaPadula upside down.”

It deals with integrity alone and ignores confidentiality entirely

Biba model covers integrity levels, which are analogous to sensitivity levels in Bell-LaPadula

Integrity levels cover inappropriate modification of data

Prevents unauthorized users from making modifications (1st goal of integrity)

The Biba Model

Two properties:

Simple Integrity Property: A low integrity subject will not

write or modify high integrity data

*-Property: The high integrity subject will not read low

integrity data

Read Up, Write Down - Subjects cannot read objects of

lesser integrity, subjects cannot write to objects of higher integrity

Each subject and object in the system is assigned an

integrity classification

– Crucial

– Important

– Unknown

Integrity Level

Integrity level of a user reflects user’s

trustworthiness for inserting, modifying, or deleting information

Integrity level of an object reflects both the

degree of trust that can be placed on the info stored in the object, and the potential

damage could result from unauthorized

modification of info

Q: How to control both the secrecy and integrity?

Applying Mandatory Policies to Databases

Commercial DBMSs Oracle, Sybase, and TruData have MLS versions

of their DBMS

Because of Bell-LaPadula restrictions, subjects having different

clearances see different versions of a multilevel relation

Visible to a user with unclassified level

Visible to a user with secret

level

Request by low level subject

– An unclassified subject request insert of <Ann, Dept1, 100K>

If this update is rejected, then the user would be able to infer something about Ann

MLS would allow the secret channel to permit data

update and protect data integrity

Visible to a user with secret

level

Visible to a user with unclassified level

Request by high level subjects

– A secret subject request to insert <Bob, Dept2, 200K>

– Inform the subject of the conflict and refuse the insertion (no)

– Overwrite the existing tuple (no)

Cover Stories

– Non-true data to hide the existence of the actual value

– Not released is a cause of information leakage

Fine-grained is not easy

– Aggregation, association

– Block inference channels

Covert Channels

A covert channel is an information flow that is not

controlled by a security mechanism

In BLP, you could use the access control mechanism itself

to construct a covert channel

– A low level subject makes an object “dummy.obj” at its own level.

– Its high level accomplice either upgrades the security level of

dummy.obj to high or leaves it unchanged.

– Later, the low level subject tries to read dummy.obj Success or

failure of this request disclose the action of the high-level subject

• One bit of information has flown from high to low

• Failure means dummy.obj has be upgraded; success means dummy.obj

has not been changed

Covert Channels (cont’d)

Other Examples for Covert Channels:

– Timing Channels

– Resource State

– Hidden Information in downgraded documents

Commonly used techniques for reducing covert channels:

– Reduce abusable functionality

– High level processes get lowest resource allocation priority and can be preempted by low level processes.

– Random delays, clock noise, randomized resource availability – Auditing the use of known channels

– Polyinstantiation

responsible for spying on another.

Also known as compartmentation

Multilateral Security

Multilateral security models:

– The Chinese Wall Model

– The BMA Model (British Medical Association)

Chinese Wall Model

Organize entities into “conflict of interest” classes

Control subject accesses to each class

Control writing to all classes to ensure

information is not passed along in violation

of rules

Allow sanitized data to be viewed by

everyone

The Chinese Wall Model

Proposed by Brewer and Nash to model access rules in a consultancy business where analysts have to make sure that no conflicts of interest arise when they are dealing with different clients

Informally, conflicts arise because clients are direct

competitors in the same market or because of the

ownership of companies Analysts have to adhere to the following security policy:

– Rule: There must be no information flow that causes a conflict of

interest.

Conflict of Interest (CoI) classes: indicate which

companies are in competition

The Chinese Wall Model

Consider a consulting business

A consultant is authorized to work for any client, but some clients have secrecy and integrity requirements relative to other clients

– Coca-Cola and Pespi

The Chinese Wall model enables definition of such

scenarios

– Only allow subjects to read data from one of the conflicted parties – Must control writing too