1cs691 chow

C. Edward ChowC. Edward Chow

Confidentiality PolicyConfidentiality Policy

CS691 – Chapter 5 of Matt Bishop

2cs691 chow

Goals of Confidentiality PoliciesGoals of Confidentiality Policies

Confidentiality Policies emphasize the protection of confidentiality.

Confidentiality policy also called information flow policy, prevents unauthorized disclosure of information.

Example: Privacy Act requires that certain personal data be kept confidential. E.g., income tax return info only available to IRS and legal authority with court order. It limits the distribution of documents/info.

Confidentiality Policies emphasize the protection of confidentiality.

Confidentiality policy also called information flow policy, prevents unauthorized disclosure of information.

Example: Privacy Act requires that certain personal data be kept confidential. E.g., income tax return info only available to IRS and legal authority with court order. It limits the distribution of documents/info.

3cs691 chow

Discretionary Access Control (DAC)Discretionary Access Control (DAC)

Definition 4-13: Mechanism where a user can set access control to allow or deny access to an object

Also called Identity-based access control (IBAC) Section 4.4. It is a traditional access control techniques implemented by

traditional operating system such as Unix. Based on user identity and ownership Programs run by a user inherits all privileges granted to the

user. Programs is free to change access to the user’s objects Support only two major categories of users:

– Completely trusted admins– Completely untrusted ordinary users

Definition 4-13: Mechanism where a user can set access control to allow or deny access to an object

Also called Identity-based access control (IBAC) Section 4.4. It is a traditional access control techniques implemented by

traditional operating system such as Unix. Based on user identity and ownership Programs run by a user inherits all privileges granted to the

user. Programs is free to change access to the user’s objects Support only two major categories of users:

– Completely trusted admins– Completely untrusted ordinary users

4cs691 chow

Problems with DACProblems with DAC Each users has complete discretion over his objects.

What is wrong with that? Difficult to enforce a system-wide security policy, e.g.

– A user can leak classified documents to a unclassified users.– Other examples?

Only based user’s identity and ownership, Ignoring security relevant info such as User’s role Function of the program Trustworthiness of the program

– Compromised program can change access to the user’s objects– Compromised program inherit all the permissions granted to the users

(especially the root user) Sensitivity of the data Integrity of the data

Only support coarse-grained privileges Unbounded privilege escalation Too simple classification of users (How about more than two categories of users?)

Each users has complete discretion over his objects. What is wrong with that? Difficult to enforce a system-wide security policy, e.g.

– A user can leak classified documents to a unclassified users.– Other examples?

Only based user’s identity and ownership, Ignoring security relevant info such as User’s role Function of the program Trustworthiness of the program

– Compromised program can change access to the user’s objects– Compromised program inherit all the permissions granted to the users

(especially the root user) Sensitivity of the data Integrity of the data

Only support coarse-grained privileges Unbounded privilege escalation Too simple classification of users (How about more than two categories of users?)

5cs691 chow

Mandatory Access Control (MAC)Mandatory Access Control (MAC)

Definition 4-14: Mechanism where system control access to an object and a user cannot alter that access.

Occasionally called rule-based access control? Defined by three major properties:

Administratively-defined security policyControl over all subjects (process) and objects (files,

sockets, network interfaces)Decisions based on all security-relevant info

MAC access decisions are based on labels that contains security-relevant info.

Definition 4-14: Mechanism where system control access to an object and a user cannot alter that access.

Occasionally called rule-based access control? Defined by three major properties:

Administratively-defined security policyControl over all subjects (process) and objects (files,

sockets, network interfaces)Decisions based on all security-relevant info

MAC access decisions are based on labels that contains security-relevant info.

6cs691 chow

What Can MAC Offer?What Can MAC Offer?

Supports a wide variety of categories of users in system. For example, Users with labels: (secret, {EUR, US}) (top secret,

{NUC, US}). Here security level is specified by the two-tuple: (clearance,

category) Strong separation of security domains System, application, and data integrity Ability to limit program privileges

Confine the damage caused by flowed or malicious software Processing pipeline guarantees Authorization limits for legitimate users

Supports a wide variety of categories of users in system. For example, Users with labels: (secret, {EUR, US}) (top secret,

{NUC, US}). Here security level is specified by the two-tuple: (clearance,

category) Strong separation of security domains System, application, and data integrity Ability to limit program privileges

Confine the damage caused by flowed or malicious software Processing pipeline guarantees Authorization limits for legitimate users

7cs691 chow

Mandatory and Discretionary Access Control

Mandatory and Discretionary Access Control

Bell-LaPadula model combines Mandatory and Discretionary Access Controls.

“S has discretionary read (write) access to O”

means that the access control matrix entry for S and O corresponding to the discretionary access control component contains a read (write) right.

A B C D OQS read(D)T

If the mandatory controls not present, S would be able to read (write) O.

Bell-LaPadula model combines Mandatory and Discretionary Access Controls.

“S has discretionary read (write) access to O”

means that the access control matrix entry for S and O corresponding to the discretionary access control component contains a read (write) right.

A B C D OQS read(D)T

If the mandatory controls not present, S would be able to read (write) O.

8cs691 chow

Bell-LaPadula ModelBell-LaPadula Model

Also called the multi-level model, Was proposed by Bell and LaPadula of MITRE for enforcing access

control in government and military applications. It corresponds to military-style classifications. In such applications, subjects and objects are often partitioned into

different security levels. A subject can only access objects at certain levels determined by

his security level. For instance, the following are two typical access specifications:

``Unclassified personnel cannot read data at confidential levels'' and ``Top-Secret data cannot be written into the files at unclassified levels''

Also called the multi-level model, Was proposed by Bell and LaPadula of MITRE for enforcing access

control in government and military applications. It corresponds to military-style classifications. In such applications, subjects and objects are often partitioned into

different security levels. A subject can only access objects at certain levels determined by

his security level. For instance, the following are two typical access specifications:

``Unclassified personnel cannot read data at confidential levels'' and ``Top-Secret data cannot be written into the files at unclassified levels''

9cs691 chow

Informal DescriptionInformal Description

Simplest type of confidentiality classification is a set of security clearances arranged in a linear (total) ordering.

Clearances represent the security levels. The higher the clearance, the more sensitive the info. Basic confidential classification system:

individuals documents

Top Secret (TS) Tamara, Thomas Personnel Files

Secret (S) Sally, Samuel Electronic Mails

Confidential (C) Claire, Clarence Activity Log Files

Unclassified (UC) Ulaley, Ursula Telephone Lists

Simplest type of confidentiality classification is a set of security clearances arranged in a linear (total) ordering.

Clearances represent the security levels. The higher the clearance, the more sensitive the info. Basic confidential classification system:

individuals documents

Top Secret (TS) Tamara, Thomas Personnel Files

Secret (S) Sally, Samuel Electronic Mails

Confidential (C) Claire, Clarence Activity Log Files

Unclassified (UC) Ulaley, Ursula Telephone Lists

10cs691 chow

Star Property (Preliminary Version)Star Property (Preliminary Version)

Let L(S)=ls be the security clearance of subject S. Let L(O)=lo be the security classification of object ). For all security classification li, i=0,…, k-1, li<li+1 Simple Security Condition:

S can read O if and only if lo<=ls and S has discretionary read access to O.

*-Property (Star property): S can write O if and only if ls<=lo and S has discretionary write access to O.

TS guy can not write documents lower than TS. Prevent classified information leak.

But how can different groups communicate?

Let L(S)=ls be the security clearance of subject S. Let L(O)=lo be the security classification of object ). For all security classification li, i=0,…, k-1, li<li+1 Simple Security Condition:

S can read O if and only if lo<=ls and S has discretionary read access to O.

*-Property (Star property): S can write O if and only if ls<=lo and S has discretionary write access to O.

TS guy can not write documents lower than TS. Prevent classified information leak.

But how can different groups communicate?

11cs691 chow

Basic Security TheoremBasic Security Theorem

Let be a system with secure initial state 0

Let T be the set of state transformations. If every element of T preserves the simple security

condition, preliminary version, and the *-property, preliminary version, Then every state i, i≥0, is secure.

Let be a system with secure initial state 0

Let T be the set of state transformations. If every element of T preserves the simple security

condition, preliminary version, and the *-property, preliminary version, Then every state i, i≥0, is secure.

12cs691 chow

Categories and Need to Know PrincipleCategories and Need to Know Principle

Expand the model by adding a set of categories. Each category describe a kind of information. These category arise from the “need to know” principle

no subject should be able to read objects unless reading them is necessary for that subject to perform its function.

Example: three categories: NUC, EUR, US. Each security level and category form a security level or

compartment. Subjects have clearance at (are cleared into, or are in) a

security level. Objects are at the level of (or are in) a security level.

Expand the model by adding a set of categories. Each category describe a kind of information. These category arise from the “need to know” principle

no subject should be able to read objects unless reading them is necessary for that subject to perform its function.

Example: three categories: NUC, EUR, US. Each security level and category form a security level or

compartment. Subjects have clearance at (are cleared into, or are in) a

security level. Objects are at the level of (or are in) a security level.

13cs691 chow

Security LatticeSecurity Lattice

William may be cleared into level (SECRET, {EUR}) George into level (TS, {NUC, US}). A document may be classified as (C, {EUR}) Someone with clearance at (TS, {NUC, US}) will be

denied access to document with category EUR.

William may be cleared into level (SECRET, {EUR}) George into level (TS, {NUC, US}). A document may be classified as (C, {EUR}) Someone with clearance at (TS, {NUC, US}) will be

denied access to document with category EUR.

{NUC, EUR, US}

{NUC, EUR} {NUC, US} {EUR, US}

{NUC} {EUR} {US}

14cs691 chow

Dominate (dom) RelationDominate (dom) Relation

The security level (L, C) dominates the security level (L’, C’) if and only if L’ L and C’ C

Dom dominate relation is false. Geroge is cleared into security level (S, {NUC, EUR}) DocA is classified as (C, {NUC}) DocB is classified as (S, {EUR, US}) DocC is classified as (S, {EUR}) George dom DocA George dom DocB George dom DocC

The security level (L, C) dominates the security level (L’, C’) if and only if L’ L and C’ C

Dom dominate relation is false. Geroge is cleared into security level (S, {NUC, EUR}) DocA is classified as (C, {NUC}) DocB is classified as (S, {EUR, US}) DocC is classified as (S, {EUR}) George dom DocA George dom DocB George dom DocC

15cs691 chow

New Security Condition and *-PropertyNew Security Condition and *-Property

Let C(S) be the category set of subject S. Let C(O) be the category set of object O. Simple Security Condition (not read up):

S can read O if and only if S dom O and S has discretionary read access to O.

*-Property (not write down): S can write to O if and only if O dom S and S has discretionary write access to O.

Basic Security Theorem: Let be a system with secure initial state 0

Let T be the set of state transformations.If every element of T preserves the simple security condition, preliminary version, and the *-property, preliminary version, Then every state i, i≥0, is secure.

Let C(S) be the category set of subject S. Let C(O) be the category set of object O. Simple Security Condition (not read up):

S can read O if and only if S dom O and S has discretionary read access to O.

*-Property (not write down): S can write to O if and only if O dom S and S has discretionary write access to O.

Basic Security Theorem: Let be a system with secure initial state 0

Let T be the set of state transformations.If every element of T preserves the simple security condition, preliminary version, and the *-property, preliminary version, Then every state i, i≥0, is secure.

16cs691 chow

Allow Write Down?Allow Write Down?

Bell-LaPadula allows higher-level subject to write into lower level object that low level subject can read.

A subject has a maximum security level and a current security level. maximum security level must dominate current security level.

A subject may (effectively) decrease its security level from the maximum in order to communicate with entities at lower security levels.

Colonel’s maximum security level is (S, {NUC, EUR}). She changes her current security level to (S, {EUR}). Now she can create document at Major is clearance level (S, {EUR}).

Bell-LaPadula allows higher-level subject to write into lower level object that low level subject can read.

A subject has a maximum security level and a current security level. maximum security level must dominate current security level.

A subject may (effectively) decrease its security level from the maximum in order to communicate with entities at lower security levels.

Colonel’s maximum security level is (S, {NUC, EUR}). She changes her current security level to (S, {EUR}). Now she can create document at Major is clearance level (S, {EUR}).

17cs691 chow

Data General B2 Unix SystemData General B2 Unix System

Data General B2 Unix (DG/UX) provides mandatory access controls (MAC).

The MAC label is a label identifying a particular compartment. The initial label (assigned at login time) is the label assigned to the

user in a database called Authorization and Authentication (A&A) Database.

When a process begins, it is assigned to MAC label of its parent (whoever creates it).

Objects are assigned labels at creation. The labels can be explicit or implicit.

The explicit label is stored as parts of the object’s attributes. The implicit label derives from the parent directory of the object. IMPL_HI: the least upper bound of all components in DG/UX lattice

has IMPL_HI as label. IMPL_LO: the greatest lower bound of all components in DG/UX

lattice has IMPL_LO as the label

Data General B2 Unix (DG/UX) provides mandatory access controls (MAC).

The MAC label is a label identifying a particular compartment. The initial label (assigned at login time) is the label assigned to the

user in a database called Authorization and Authentication (A&A) Database.

When a process begins, it is assigned to MAC label of its parent (whoever creates it).

Objects are assigned labels at creation. The labels can be explicit or implicit.

The explicit label is stored as parts of the object’s attributes. The implicit label derives from the parent directory of the object. IMPL_HI: the least upper bound of all components in DG/UX lattice

has IMPL_HI as label. IMPL_LO: the greatest lower bound of all components in DG/UX

lattice has IMPL_LO as the label

18cs691 chow

Three MAC Regions in DG/UX MAC Lattice

Three MAC Regions in DG/UX MAC Lattice

Figure 5-3 The three MAC regions in the MAC lattice (modified from the DG/UX Security Manual [257], p. 4-7, Figure 4-4). TCB stands for "trusted computing base.“

19cs691 chow

Accesses with MAC LabelsAccesses with MAC Labels

• Read up and write up from users to Admin Region not allowed.

• Admin processes sanitize data sent to user processes with MAC Labels in the user region.

• System programs are in the lowest region.• No user can write to or alter them.• Only programs with the same label as the directory

can create files in that directory.• The above restriction will prevent

• compiling (need to access /tmp)• mail delivery (need to access mail spool

directory)• Solution multilevel directory.

• Read up and write up from users to Admin Region not allowed.

• Admin processes sanitize data sent to user processes with MAC Labels in the user region.

• System programs are in the lowest region.• No user can write to or alter them.• Only programs with the same label as the directory

can create files in that directory.• The above restriction will prevent

• compiling (need to access /tmp)• mail delivery (need to access mail spool

directory)• Solution multilevel directory.

20cs691 chow

Multilevel DirectoryMultilevel Directory

A directory with a set of subdirectories, one for each label. These hidden directories normally invisible to the user. When a process with label MAC_A creates a file in /tmp, it actually

create a file in hidden directory under /tmp with label MAC_A The parent directory of a file in /tmp is the hidden directory. A reference to the parent directory goes to the hidden directory. Process A with MAC_A creates /tmp/a. Process B with MAC_B

creates /tmp/a. Each of them performs “cd /tmp/a; cd ..”The system call stat(“.”, &stat_buffer) returns different inode number for each process. It returns the inode number of the respective hidden directory.

Try “stat” command to display file and related status. DG/UX provides dg_mstat(“.”, &stat_buffer) to translate the current

working directory to the multilevel directory

A directory with a set of subdirectories, one for each label. These hidden directories normally invisible to the user. When a process with label MAC_A creates a file in /tmp, it actually

create a file in hidden directory under /tmp with label MAC_A The parent directory of a file in /tmp is the hidden directory. A reference to the parent directory goes to the hidden directory. Process A with MAC_A creates /tmp/a. Process B with MAC_B

creates /tmp/a. Each of them performs “cd /tmp/a; cd ..”The system call stat(“.”, &stat_buffer) returns different inode number for each process. It returns the inode number of the respective hidden directory.

Try “stat” command to display file and related status. DG/UX provides dg_mstat(“.”, &stat_buffer) to translate the current

working directory to the multilevel directory

21cs691 chow

Mounting Unlabeled File SystemMounting Unlabeled File System All files in that file system need to be labeled. Symbolic links aggravate this problem. Does the MAC label the target of the link

control, or does the MAC label the link itself? DG/UX uses a notion of inherited labels (called implicit labels) to solve this problem.

The following rules control the way objects are labeled.1. Roots of file systems have explicit MAC labels. If a file system without labels is

mounted on a labeled file system, the root directory of the mounted file system receives an explicit label equal to that of the mount point. However, the label of the mount point, and of the underlying tree, is no longer visible, and so its label is unchanged (and will become visible again when the file system is unmounted).

2. An object with an implicit MAC label inherits the label of its parent.3. When a hard link to an object is created, that object must have an explicit label; if it

does not, the object's implicit label is converted to an explicit label. A corollary is that moving a file to a different directory makes its label explicit.

4. If the label of a directory changes, any immediate children with implicit labels have those labels converted to explicit labels before the parent directory's label is changed.

5. When the system resolves a symbolic link, the label of the object is the label of the target of the symbolic link. However, to resolve the link, the process needs access to the symbolic link itself.

All files in that file system need to be labeled. Symbolic links aggravate this problem. Does the MAC label the target of the link

control, or does the MAC label the link itself? DG/UX uses a notion of inherited labels (called implicit labels) to solve this problem.

The following rules control the way objects are labeled.1. Roots of file systems have explicit MAC labels. If a file system without labels is

mounted on a labeled file system, the root directory of the mounted file system receives an explicit label equal to that of the mount point. However, the label of the mount point, and of the underlying tree, is no longer visible, and so its label is unchanged (and will become visible again when the file system is unmounted).

2. An object with an implicit MAC label inherits the label of its parent.3. When a hard link to an object is created, that object must have an explicit label; if it

does not, the object's implicit label is converted to an explicit label. A corollary is that moving a file to a different directory makes its label explicit.

4. If the label of a directory changes, any immediate children with implicit labels have those labels converted to explicit labels before the parent directory's label is changed.

5. When the system resolves a symbolic link, the label of the object is the label of the target of the symbolic link. However, to resolve the link, the process needs access to the symbolic link itself.

22cs691 chow

Interesting Case with Hard LinksInteresting Case with Hard Links Let /x/y/z: and /x/a/b be hard links to the same object. Suppose y has an explicit

label IMPL_HI and a an explicit label IMPL_B. Then the file object can be accessed by a process at IMPL_HI as /x/y/z and by a process at IMPL_B as /x/alb. Which label is correct? Two cases arise.

Suppose the hard link is created while the file system is on a DG/UX B2 system. Then the DG/UX system converts the target's implicit label to an explicit one (rule 3). Thus, regardless of the path used to refer to the object, the label of the object will be the same.

Suppose the hard link exists when the file system is mounted on the DG/UX B2 system. In this case, the target had no file label when it was created, and one must be added. If no objects on the paths to the target have explicit labels, the tar get will have the same (implicit) label regardless of the path being used. But if any object on any path to the target of the link acquires an explicit label, the target's label may depend on which path is taken. To avoid this, the implicit labels of a directory's children must be preserved when the directory's label is made explicit. Rule 4 does this.

Because symbolic links interpolate path names of files, rather than store Mode numbers, computing the label of symbolic links is straightforward. If /x/y/z is a sym bolic link to /a/b/c, then the MAC label of c is computed in the usual way. However, the symbolic link itself is a file, and so the process must also have access to the link file z.

Let /x/y/z: and /x/a/b be hard links to the same object. Suppose y has an explicit label IMPL_HI and a an explicit label IMPL_B. Then the file object can be accessed by a process at IMPL_HI as /x/y/z and by a process at IMPL_B as /x/alb. Which label is correct? Two cases arise.

Suppose the hard link is created while the file system is on a DG/UX B2 system. Then the DG/UX system converts the target's implicit label to an explicit one (rule 3). Thus, regardless of the path used to refer to the object, the label of the object will be the same.

Suppose the hard link exists when the file system is mounted on the DG/UX B2 system. In this case, the target had no file label when it was created, and one must be added. If no objects on the paths to the target have explicit labels, the tar get will have the same (implicit) label regardless of the path being used. But if any object on any path to the target of the link acquires an explicit label, the target's label may depend on which path is taken. To avoid this, the implicit labels of a directory's children must be preserved when the directory's label is made explicit. Rule 4 does this.

Because symbolic links interpolate path names of files, rather than store Mode numbers, computing the label of symbolic links is straightforward. If /x/y/z is a sym bolic link to /a/b/c, then the MAC label of c is computed in the usual way. However, the symbolic link itself is a file, and so the process must also have access to the link file z.

23cs691 chow

Enable Flexible Write in DG/UXEnable Flexible Write in DG/UX

Provide a range of labels called MAC tuple. A range is a set of labels expressed by a lower bound and an upper

hound. A MAC tuple consists of up to three ranges (one for each of the regions in Figure 5-3).

Example: A system has two security levels. TS and S, the former dominating the latter. The categories are COMP. NUC, and ASIA. Examples of ranges are:

[(S, { COMP } ), (TS, { COMP } )] [( S, ), (TS, { COMP, NUC. ASIA } )] [( S, { ASIA } ), ( TS, { ASIA, NUC } )] The label ( TS, { COMP }) is in the first two ranges.

The label ( S, { NUC, ASIA } ) is in the last two ranges. However,[( S, {ASIA} ), ( TS, { COMP, NUC} )]is not a valid range because ( TS, {COMP. NUC } ) dom ( S, { ASIA } ).

Provide a range of labels called MAC tuple. A range is a set of labels expressed by a lower bound and an upper

hound. A MAC tuple consists of up to three ranges (one for each of the regions in Figure 5-3).

Example: A system has two security levels. TS and S, the former dominating the latter. The categories are COMP. NUC, and ASIA. Examples of ranges are:

[(S, { COMP } ), (TS, { COMP } )] [( S, ), (TS, { COMP, NUC. ASIA } )] [( S, { ASIA } ), ( TS, { ASIA, NUC } )] The label ( TS, { COMP }) is in the first two ranges.

The label ( S, { NUC, ASIA } ) is in the last two ranges. However,[( S, {ASIA} ), ( TS, { COMP, NUC} )]is not a valid range because ( TS, {COMP. NUC } ) dom ( S, { ASIA } ).

24cs691 chow

Formal ModelFormal Model

Let S be the set of subjects of a system and let O be the set of objects. Let P be the set of rights r for read, a for write, w for read/write, and e for empty.

Let M be a set of possible access control matrices for the system. Let C be the set of classifications (or clearances), let K be the set of categories, and let L = C x K be the set of security levels. Finally, let F be the set of 3-tuples (fs,fo,fc), where fs and, fc associate with each subject maximum and current security levels, respectively, and, fo, associates with each object a security level.

The system objects may be organized as a set of hierarchies (trees and single nodes).

Let H represent the set of hierarchy functions h: OP(O). P(O) is the power set of O, i.e., the set of all possible subsets of O.

The hierarchy functions have two properties: Let oi, oj, ok O.1. If oi oj, then h(oi) h(oj) = .2. There is no set { o1, o2, ..., ok } O such that

for each i = 1, ..., k, oi+1 h(oi), and ok+1= o1.

Let S be the set of subjects of a system and let O be the set of objects. Let P be the set of rights r for read, a for write, w for read/write, and e for empty.

Let M be a set of possible access control matrices for the system. Let C be the set of classifications (or clearances), let K be the set of categories, and let L = C x K be the set of security levels. Finally, let F be the set of 3-tuples (fs,fo,fc), where fs and, fc associate with each subject maximum and current security levels, respectively, and, fo, associates with each object a security level.

The system objects may be organized as a set of hierarchies (trees and single nodes).

Let H represent the set of hierarchy functions h: OP(O). P(O) is the power set of O, i.e., the set of all possible subsets of O.

The hierarchy functions have two properties: Let oi, oj, ok O.1. If oi oj, then h(oi) h(oj) = .2. There is no set { o1, o2, ..., ok } O such that

for each i = 1, ..., k, oi+1 h(oi), and ok+1= o1.

25cs691 chow

Formal Model: State, RequestFormal Model: State, Request A state v V of a system is a 4-tuple (b, m, f, h), where

b P(S x O x P) indicates which subjects have access to which objects, and what those access rights are:

m M is the access control matrix for the current state; f F is the 3-tuple indicating the current subject and object clearances and

categories; and h H is the hierarchy of objects for the current state.

The difference between b and m is that the rights in m may be unusable because of differences in security levels; b contains the set of rights that may be exercised, and m contains the set of discretionary rights.

R denotes the set of requests for access. Four outcomes of each request are possible: y for yes (allowed), n for no (not allowed), i for illegal request, and o for error (multiple outcomes are possible).

D denotes the set of outcomes. The set W R x D x V x V is the set of actions of the system. This notation means that an entity issues a request in R, and a decision in D occurs, moving the system from one state in V to another (possibly different) state in V.

A state v V of a system is a 4-tuple (b, m, f, h), where b P(S x O x P) indicates which subjects have access to which objects, and

what those access rights are: m M is the access control matrix for the current state; f F is the 3-tuple indicating the current subject and object clearances and

categories; and h H is the hierarchy of objects for the current state.

The difference between b and m is that the rights in m may be unusable because of differences in security levels; b contains the set of rights that may be exercised, and m contains the set of discretionary rights.

R denotes the set of requests for access. Four outcomes of each request are possible: y for yes (allowed), n for no (not allowed), i for illegal request, and o for error (multiple outcomes are possible).

D denotes the set of outcomes. The set W R x D x V x V is the set of actions of the system. This notation means that an entity issues a request in R, and a decision in D occurs, moving the system from one state in V to another (possibly different) state in V.

26cs691 chow

Formal Model: History, SystemFormal Model: History, System

Let N be the set of positive integers. These integers represent times. Let X = RN be a set whose elements x are sequences of requests, let Y = DN be a set whose elements y are sequences of decisions, and let Z = VN be a set whose elements z are sequences of states. The ith components of x, y, and z are represented as xi, yi, and zi. respectively.

The interpretation is that for some t N, the system is in state zt-1 V, a subject makes request xt R, the system makes a decision yt D, and as a result the system transitions into a (possibly new) state zt V

A system is represented as an initial state and a sequence of requests, deci sions, and states.

In formal terms, (R, D, W, z0) X x Y x Z represents the system, and z0 is the initial state of the system.(x, y, z) (R, D, W, z0) if and only if (xt, yt, zt, zt-1) W for all t N.

(x, y, z) is an appearance of (R, D, W, z0) .

Let N be the set of positive integers. These integers represent times. Let X = RN be a set whose elements x are sequences of requests, let Y = DN be a set whose elements y are sequences of decisions, and let Z = VN be a set whose elements z are sequences of states. The ith components of x, y, and z are represented as xi, yi, and zi. respectively.

The interpretation is that for some t N, the system is in state zt-1 V, a subject makes request xt R, the system makes a decision yt D, and as a result the system transitions into a (possibly new) state zt V

A system is represented as an initial state and a sequence of requests, deci sions, and states.

In formal terms, (R, D, W, z0) X x Y x Z represents the system, and z0 is the initial state of the system.(x, y, z) (R, D, W, z0) if and only if (xt, yt, zt, zt-1) W for all t N.

(x, y, z) is an appearance of (R, D, W, z0) .

27cs691 chow

Simple Security Condition, *-PropertySimple Security Condition, *-Property

Definition 5-2. (s, o, p) S x O x P satisfies the simple security condition relative to f (written as ssc rel f) if and only if one of the following holds:

a. p=e or p=a

b. p = r or p = w and fc(s) dom fo(o)

Define b(s: p1, ..., pn) to be the set of all objects that s has p1, ..., pn access to.

b(s: p1, ..., pn)={ o | oO [(s,o,p1)b ...(s,o,pn)b]}

Definition 5-3. A state (h, m, f, h) satisfies the *-property if and only if, for each s S. the following hold:a. b(s: a) [ ob(s: a) [fo(o) dom fc(s)] ]b. b(s: w) [ ob(s: w) [fo(o) = fc(s)] ]c. b(s: r) [ ob(s: r) [fc(s) dom fo(o)] ]

Definition 5-2. (s, o, p) S x O x P satisfies the simple security condition relative to f (written as ssc rel f) if and only if one of the following holds:

a. p=e or p=a

b. p = r or p = w and fc(s) dom fo(o)

Define b(s: p1, ..., pn) to be the set of all objects that s has p1, ..., pn access to.

b(s: p1, ..., pn)={ o | oO [(s,o,p1)b ...(s,o,pn)b]}

Definition 5-3. A state (h, m, f, h) satisfies the *-property if and only if, for each s S. the following hold:a. b(s: a) [ ob(s: a) [fo(o) dom fc(s)] ]b. b(s: w) [ ob(s: w) [fo(o) = fc(s)] ]c. b(s: r) [ ob(s: r) [fc(s) dom fo(o)] ]

28cs691 chow

Discretionary Security Property, ActionDiscretionary Security Property, Action

Definition 5-4. A state (b, m, f, h) satisfies the discretionary security property (ds-property) if and only if, for each triple (s, o, p) b, p m[s, o].

Definition 5-5. A system is secure if it satisfies the simple security condition, the *-property, and the discretionary security property

Definition 5-6. (r, d, v, v') R x D x V x V is an action of (R, D, W, z0) if and only if there is an (x, y, z) (R, D, W, z0) and a t N such that (r, d, v, v') = (xt, yt, zt, zt-1)

An action is a request/decision pair that occurs during the execution of the system.

Definition 5-4. A state (b, m, f, h) satisfies the discretionary security property (ds-property) if and only if, for each triple (s, o, p) b, p m[s, o].

Definition 5-5. A system is secure if it satisfies the simple security condition, the *-property, and the discretionary security property

Definition 5-6. (r, d, v, v') R x D x V x V is an action of (R, D, W, z0) if and only if there is an (x, y, z) (R, D, W, z0) and a t N such that (r, d, v, v') = (xt, yt, zt, zt-1)

An action is a request/decision pair that occurs during the execution of the system.

29cs691 chow

When the three properties holdWhen the three properties hold

Theorem 5-3. (R, D, W, z0) satisfies the simple security condition for any secure state z0 if and only if, for every action (r, d, (b, m, f, h), (b', m', f', h')), W satisfies the following:a. Every (s, o, p) b - b' satisfies ssc rel f.b. Every (s, o, p) b' that does not satisfy ssc rel f is not in b.

Theorem 5-4. (R, D, W, z0) satisfies the *-property relative to S' S for any secure state z0 if and only if, for every action (r, d, (b, m, f, h), (b', m', f', h')), W satisfies the following for every s S':a. Every (s, o, p) b - b' satisfies the *-property with respect to S'.b. Every (s, o, p) b' that does not satisfy the *-property with respect to S' is not in b.

Theorem 5-5. (R, D, W, z0) satisfies the ds-property for any secure state z0 if and only if, for every action (r, d, (b, m, f, h), (b', m', f', h')), W satisfies the following:a. Every (s, o, p) b - b ' satisfies the ds-property.b. Every (s, o, p) b' that does not satisfy the ds-property is not in b.

Theorem 5-6. Basic Security Theorem: (R, D. W, z0) is a secure system if z0 is a secure state and W satisfies the conditions of Theorems 5-3, 5-4, and 5-5.

Theorem 5-3. (R, D, W, z0) satisfies the simple security condition for any secure state z0 if and only if, for every action (r, d, (b, m, f, h), (b', m', f', h')), W satisfies the following:a. Every (s, o, p) b - b' satisfies ssc rel f.b. Every (s, o, p) b' that does not satisfy ssc rel f is not in b.

Theorem 5-4. (R, D, W, z0) satisfies the *-property relative to S' S for any secure state z0 if and only if, for every action (r, d, (b, m, f, h), (b', m', f', h')), W satisfies the following for every s S':a. Every (s, o, p) b - b' satisfies the *-property with respect to S'.b. Every (s, o, p) b' that does not satisfy the *-property with respect to S' is not in b.

Theorem 5-5. (R, D, W, z0) satisfies the ds-property for any secure state z0 if and only if, for every action (r, d, (b, m, f, h), (b', m', f', h')), W satisfies the following:a. Every (s, o, p) b - b ' satisfies the ds-property.b. Every (s, o, p) b' that does not satisfy the ds-property is not in b.

Theorem 5-6. Basic Security Theorem: (R, D. W, z0) is a secure system if z0 is a secure state and W satisfies the conditions of Theorems 5-3, 5-4, and 5-5.

30cs691 chow

Rules of TransformationRules of Transformation

A rule is a function :R x VD x V Intuitively, a rule takes a state and a request, and determines if the request meets the conditions of the rule (the decision). If so, it moves the system to a (possibly different) state.

Definition 5-7. A rule p is ssc-preserving, if, for all (r, v) R x V and v satisfying ssc rel f, (r, v) = (d, v') means that v' satisfies ssc rel f'.

Similar definitions hold for the property and the ds-property. If a rule is ssc preserving, *-property-preserving, and ds-property-preserving, the rule is said to be security-preserving.

Definition 5-8. Let w = {1, ..., m } be a set of rules. For request r R, decision d D, and states v, v' V, (r, d, v, v') W() if and only if d i and there is a unique integer i, 1 ≤ i ≤ m, such that i(r, v) = (d, v' ).

This definition says that if the request is legal and there is only one rule that will change the state of the system from v to v', the corresponding action is in W().

A rule is a function :R x VD x V Intuitively, a rule takes a state and a request, and determines if the request meets the conditions of the rule (the decision). If so, it moves the system to a (possibly different) state.

Definition 5-7. A rule p is ssc-preserving, if, for all (r, v) R x V and v satisfying ssc rel f, (r, v) = (d, v') means that v' satisfies ssc rel f'.

Similar definitions hold for the property and the ds-property. If a rule is ssc preserving, *-property-preserving, and ds-property-preserving, the rule is said to be security-preserving.

Definition 5-8. Let w = {1, ..., m } be a set of rules. For request r R, decision d D, and states v, v' V, (r, d, v, v') W() if and only if d i and there is a unique integer i, 1 ≤ i ≤ m, such that i(r, v) = (d, v' ).

This definition says that if the request is legal and there is only one rule that will change the state of the system from v to v', the corresponding action is in W().

31cs691 chow

When rule set preserves simple security condition?

When rule set preserves simple security condition?

Theorem 5-7. Let be a set of ssc-preserving rules, and let z0 be a state satisfying the simple security condition. Then (R, D, W, z0) satisfies the simple security condition.

When does adding a state preserve the simple security property? Theorem 5-8. Let v = (b, m, f, h) satisfy the simple security

condition. Let (s, o, p) b, b' = b {(s, o, p) }, and v' = (b', m, f, h). Then v' satisfies the simple security condition if and only if either of the following conditions is true.a. Either p = e or p = a.b. Either p = r or p = w, and fs(s) dom fo(o).

Theorem 5-9. Let be a set of *-property-preserving rules, and let z0 be a state satisfying the *-property. Then (R, D, W, z0) satisfies the *-property.

Theorem 5-7. Let be a set of ssc-preserving rules, and let z0 be a state satisfying the simple security condition. Then (R, D, W, z0) satisfies the simple security condition.

When does adding a state preserve the simple security property? Theorem 5-8. Let v = (b, m, f, h) satisfy the simple security

condition. Let (s, o, p) b, b' = b {(s, o, p) }, and v' = (b', m, f, h). Then v' satisfies the simple security condition if and only if either of the following conditions is true.a. Either p = e or p = a.b. Either p = r or p = w, and fs(s) dom fo(o).

Theorem 5-9. Let be a set of *-property-preserving rules, and let z0 be a state satisfying the *-property. Then (R, D, W, z0) satisfies the *-property.

32cs691 chow

Properties Properties Theorem 5-10. Let v= (b, m, f, h) satisfy the *-property. Let (s, o, p) b, b' = b { (s,

o, p) }, and v' = (b', m, f, h). Then v' satisfies the *-property if and only if one of the following conditions holds.a. p = a and fo(o) dom fc(s) b. p = w and. fo(o) = fc(s) c. p = r and fc(s) dom fo(o)

Theorem 5-11. Let be a set of ds-property-preserving rules, and let z0 be a state satisfying the ds-property. Then (R, D, W, z0) satisfies the ds-property.

Theorem 5-12. Let v = (b, m,,f; h) satisfy the ds-property. Let (s, o, p) b, b' = b { (s, o. p) }, and v' = (b', m, f, h). Then v' satisfies the ds-property if and only if p m[s, o].

Theorem 5-13. Let he a rule and (r, v) = (d, v'), where v= (b, m, f, h) and v' = (b', m', f', h'). Then:a. If b' b, f'=,f, and v satisfies the simple security condition, then v‘ satisfies the simple security condition.b. If b' h, f' =f, and v satisfies the *-property, then v' satisfies the *-property.c. If b' h, , m[s, o] m' [s, o] for all s S and o O, and v satisfies the ds- property, then v' satisfies the ds-property.

Theorem 5-10. Let v= (b, m, f, h) satisfy the *-property. Let (s, o, p) b, b' = b { (s, o, p) }, and v' = (b', m, f, h). Then v' satisfies the *-property if and only if one of the following conditions holds.a. p = a and fo(o) dom fc(s) b. p = w and. fo(o) = fc(s) c. p = r and fc(s) dom fo(o)

Theorem 5-11. Let be a set of ds-property-preserving rules, and let z0 be a state satisfying the ds-property. Then (R, D, W, z0) satisfies the ds-property.

Theorem 5-12. Let v = (b, m,,f; h) satisfy the ds-property. Let (s, o, p) b, b' = b { (s, o. p) }, and v' = (b', m, f, h). Then v' satisfies the ds-property if and only if p m[s, o].

Theorem 5-13. Let he a rule and (r, v) = (d, v'), where v= (b, m, f, h) and v' = (b', m', f', h'). Then:a. If b' b, f'=,f, and v satisfies the simple security condition, then v‘ satisfies the simple security condition.b. If b' h, f' =f, and v satisfies the *-property, then v' satisfies the *-property.c. If b' h, , m[s, o] m' [s, o] for all s S and o O, and v satisfies the ds- property, then v' satisfies the ds-property.

33cs691 chow

Multics Example (Model Instantiation)Multics Example (Model Instantiation) The Multics system [68, 788 has I 1 rules affecting the rights on the system. These rules are

divided into five groups. Let the set Q contain the set of request operations (such as get, give, and so forth). Then:

1. R(1) = Q x S x O x M. This is the set of requests to request and release access. The rules are get-read, get-append, get-execute, get-write, and release-read/execute/write/append. These rules differ in the conditions necessary for the subject to be able to request the desired right. The rule get-read is discussed in more detail in Section 5.2.4.1.

2. R(2) = S x Q x S x O x M. This is the set of requests to give access to and remove access from a different subject. The rules are give-read/execute/write/append and rescind-read/execute/write/append. Again, the rules differ in the conditions needed to acquire and delete the rights, but within each rule, the right being added or removed does not affect the conditions. Whether the right is being added or deleted does affect them. The rule give-read/execute/write/append is discussed in more detail in Section 5.2.4.2.

3. R(3) = Q x S x O x L. This is the set of requests to create and reclassify objects. It contains the create-object and change-object-security-level rules. The object's security level is either assigned (create-object) or changed (change-object-security-Ievel ).

4. R(4) = S x O. This is the set of requests to remove objects. It contains only the rule delete-object-group, which deletes an object and all objects beneath it in the hierarchy.

5. R(5) = S x L. This is the set of requests to change a subject's security level. It contains only the rule change-subject-current-security-level, which changes a subject's current security level (not the maximum security level).

Then, the set of requests R = R(1) R(2) R(3) R(4) R(5) The Multics system includes the notion of trusted users. The system does not enforce the *-

property for this set of subjects ST S, however, members of ST are trusted not to violate that property.

For each rule , define () as the domain of the request (that is, whether or not the components of the request form a valid operand for the rule).

The Multics system [68, 788 has I 1 rules affecting the rights on the system. These rules are divided into five groups. Let the set Q contain the set of request operations (such as get, give, and so forth). Then:

1. R(1) = Q x S x O x M. This is the set of requests to request and release access. The rules are get-read, get-append, get-execute, get-write, and release-read/execute/write/append. These rules differ in the conditions necessary for the subject to be able to request the desired right. The rule get-read is discussed in more detail in Section 5.2.4.1.

2. R(2) = S x Q x S x O x M. This is the set of requests to give access to and remove access from a different subject. The rules are give-read/execute/write/append and rescind-read/execute/write/append. Again, the rules differ in the conditions needed to acquire and delete the rights, but within each rule, the right being added or removed does not affect the conditions. Whether the right is being added or deleted does affect them. The rule give-read/execute/write/append is discussed in more detail in Section 5.2.4.2.

3. R(3) = Q x S x O x L. This is the set of requests to create and reclassify objects. It contains the create-object and change-object-security-level rules. The object's security level is either assigned (create-object) or changed (change-object-security-Ievel ).

4. R(4) = S x O. This is the set of requests to remove objects. It contains only the rule delete-object-group, which deletes an object and all objects beneath it in the hierarchy.

5. R(5) = S x L. This is the set of requests to change a subject's security level. It contains only the rule change-subject-current-security-level, which changes a subject's current security level (not the maximum security level).

Then, the set of requests R = R(1) R(2) R(3) R(4) R(5) The Multics system includes the notion of trusted users. The system does not enforce the *-

property for this set of subjects ST S, however, members of ST are trusted not to violate that property.

For each rule , define () as the domain of the request (that is, whether or not the components of the request form a valid operand for the rule).

34cs691 chow

The get-read Rule The get-read Rule The get-read rule enables a subject s to request the right to read an object o.

Represent this request as r = (get, s, o, r) R(1) , and let the current state of the system be v= (b, m, f, h). Then get-read is the rule 1(r, v):

if (r (1)) then 1(r, v)=(i, v);else if ( fs(s) dom fo(o) and [s ST or fc(s) dom fo(o)] and r m[s, o])

then 1(r, v)=(y, (b { (s, o, r) }, m, f, h)); else 1(r, v)=(n, v); The first if tests the parameters of the request: if any of them are incorrect, the

decision is "illegal" and the system state remains unchanged. The second if checks three conditions. The simple security property for the

maximum security level of the sub ject and the classification of the object must hold. Either the subject making the request must be trusted, or the simple security property must hold for the current security level of the subject (this allows trusted subjects to read information from objects above their current security levels but at or below their maximum security levels; they are trusted not to reveal the information inappropriately). Finally, the dis cretionary security property must hold. If these three conditions hold, so does the Basic Security Theorem. The decision is "yes" and the system state is updated to reflect the new access. Otherwise, the decision is "no" and the system state remains unchanged.

The get-read rule enables a subject s to request the right to read an object o. Represent this request as r = (get, s, o, r) R(1) , and let the current state of the system be v= (b, m, f, h). Then get-read is the rule 1(r, v):

if (r (1)) then 1(r, v)=(i, v);else if ( fs(s) dom fo(o) and [s ST or fc(s) dom fo(o)] and r m[s, o])

then 1(r, v)=(y, (b { (s, o, r) }, m, f, h)); else 1(r, v)=(n, v); The first if tests the parameters of the request: if any of them are incorrect, the

decision is "illegal" and the system state remains unchanged. The second if checks three conditions. The simple security property for the

maximum security level of the sub ject and the classification of the object must hold. Either the subject making the request must be trusted, or the simple security property must hold for the current security level of the subject (this allows trusted subjects to read information from objects above their current security levels but at or below their maximum security levels; they are trusted not to reveal the information inappropriately). Finally, the dis cretionary security property must hold. If these three conditions hold, so does the Basic Security Theorem. The decision is "yes" and the system state is updated to reflect the new access. Otherwise, the decision is "no" and the system state remains unchanged.

35cs691 chow

The give-read Rule The give-read Rule The give-read rule enables a subject s to give subject s2 the (discretionary) right to read an

object o. Conceptually, a subject can give another subject read access to an object if the giver can alter (write to) the parent of the object. If the parent is the root of the hierarchy containing the object, or if the object itself is the root of the hierarchy, the subject must be specially authorized to grant access.

Some terms simplify the definitions and proofs. Define root(o) as the root object of the hierarchy h containing o, and define parent(o) as the parent of o in h. If the subject is specially authorized to grant access to the object in the situation just mentioned, the predicate canallow(s, o, v) is true. Finally, define m m[s, o]r as the access control matrix m with the right r added to entry m[s, o].

Represent the give-read request as r = (s1, give, s2, o, r) R(2), and let the current state of the system be v = (b, m, f, h). Then, give-read is the rule 6(r, v):

if (r (6)) then 6(r, v) = (i, v);else if ( [ o root(o) and parent(o) root(o) and parent(o) b(s1: w)] or [ parent(o) = root(o) and canallow(s1, o, v) ] or [ o = root(o) and canallow(s1, root(o), v) ]) then 6(r, v) = (y, (b, m m[s2, o]r, f, h)); else 6(r, v) = (n, v); The first if tests the parameters of the request; if any of them are incorrect, the decision is

"illegal" and the system state remains unchanged. The second if checks several conditions. If neither the object nor its parent is the root of the hierarchy con taining the object, then s1 must have write rights to the parent. If the object or its par ent is the root of the hierarchy, then s1 must have special permission to give s2 the read right to o. The decision is "yes" and the access control matrix is updated to reflect the new access. Otherwise, the decision is "no" and the system state remains unchanged.

The give-read rule enables a subject s to give subject s2 the (discretionary) right to read an object o. Conceptually, a subject can give another subject read access to an object if the giver can alter (write to) the parent of the object. If the parent is the root of the hierarchy containing the object, or if the object itself is the root of the hierarchy, the subject must be specially authorized to grant access.

Some terms simplify the definitions and proofs. Define root(o) as the root object of the hierarchy h containing o, and define parent(o) as the parent of o in h. If the subject is specially authorized to grant access to the object in the situation just mentioned, the predicate canallow(s, o, v) is true. Finally, define m m[s, o]r as the access control matrix m with the right r added to entry m[s, o].

Represent the give-read request as r = (s1, give, s2, o, r) R(2), and let the current state of the system be v = (b, m, f, h). Then, give-read is the rule 6(r, v):

if (r (6)) then 6(r, v) = (i, v);else if ( [ o root(o) and parent(o) root(o) and parent(o) b(s1: w)] or [ parent(o) = root(o) and canallow(s1, o, v) ] or [ o = root(o) and canallow(s1, root(o), v) ]) then 6(r, v) = (y, (b, m m[s2, o]r, f, h)); else 6(r, v) = (n, v); The first if tests the parameters of the request; if any of them are incorrect, the decision is

"illegal" and the system state remains unchanged. The second if checks several conditions. If neither the object nor its parent is the root of the hierarchy con taining the object, then s1 must have write rights to the parent. If the object or its par ent is the root of the hierarchy, then s1 must have special permission to give s2 the read right to o. The decision is "yes" and the access control matrix is updated to reflect the new access. Otherwise, the decision is "no" and the system state remains unchanged.

36cs691 chow

Tranquility Tranquility The principle of tranquility states that subjects and objects may not change their

security levels once they have been instantiated. Suppose that security levels of objects can be changed, and consider the effects on

a system with one category and two security clearances, HIGH and LOW. If an object's security classification is raised from LOW to HIGH, then any subjects cleared to only LOW can no longer read that object. Similarly, if an object's classification is dropped from HIGH to LOW, any subject can now read that object.

Both situations violate fundamental restrictions. Raising the classification of an object means that information that was available is no

longer available; lowering the clas sification means that information previously considered restricted is now available to all.

Raising the classification of an object is not considered a problem. The model does not define how to determine the appropriate classification of information. It merely describes how to manipulate an object containing the information once that object has been assigned a classification.

declassification problem. Because this makes information available to subjects who did not have access to it before, it is in effect a "write down" that violates the

*-property. The typical solution is to define a set of trusted entities or subjects that will remove all sensitive information from the HIGH object before its classification is changed to LOW.

The principle of tranquility states that subjects and objects may not change their security levels once they have been instantiated.

Suppose that security levels of objects can be changed, and consider the effects on a system with one category and two security clearances, HIGH and LOW. If an object's security classification is raised from LOW to HIGH, then any subjects cleared to only LOW can no longer read that object. Similarly, if an object's classification is dropped from HIGH to LOW, any subject can now read that object.

Both situations violate fundamental restrictions. Raising the classification of an object means that information that was available is no

longer available; lowering the clas sification means that information previously considered restricted is now available to all.

Raising the classification of an object is not considered a problem. The model does not define how to determine the appropriate classification of information. It merely describes how to manipulate an object containing the information once that object has been assigned a classification.

declassification problem. Because this makes information available to subjects who did not have access to it before, it is in effect a "write down" that violates the

*-property. The typical solution is to define a set of trusted entities or subjects that will remove all sensitive information from the HIGH object before its classification is changed to LOW.

37cs691 chow

Strong/Weak TranquilityStrong/Weak Tranquility Definition 5-9. The principle of strong tranquility states that security levels do not

change during the lifetime of the system. Strong tranquility eliminates the need for trusted declassifiers, because no

declassification can occur. Moreover, no raising of security levels can occur. This elim inates the problems discussed above. However, strong tranquility is also inflexible and in practice is usually too strong a requirement.

Definition 5-10. The principle of weak tranquility states that security levels do not change in a way that violates the rules of a given security policy.

Weak tranquility moderates the restriction to allow harmless changes of security levels. It is more flexible, because it allows changes, but it disallows any violations of the security policy (in the context of the Bell-LaPadula Model, the simple security condition and *-property).

EXAMPLE: In the Data General DG/UX system, only the security administrator, a trusted user, can change MAC labels on objects. In general, when a user wishes to assume a new MAC label, that user must initiate a new session; the MAC labels of processes cannot be changed. However, a user may be designated as able to change a process label within a specified range. This makes the system more amenable to commercial environments.

Definition 5-9. The principle of strong tranquility states that security levels do not change during the lifetime of the system.

Strong tranquility eliminates the need for trusted declassifiers, because no declassification can occur. Moreover, no raising of security levels can occur. This elim inates the problems discussed above. However, strong tranquility is also inflexible and in practice is usually too strong a requirement.

Definition 5-10. The principle of weak tranquility states that security levels do not change in a way that violates the rules of a given security policy.

Weak tranquility moderates the restriction to allow harmless changes of security levels. It is more flexible, because it allows changes, but it disallows any violations of the security policy (in the context of the Bell-LaPadula Model, the simple security condition and *-property).

EXAMPLE: In the Data General DG/UX system, only the security administrator, a trusted user, can change MAC labels on objects. In general, when a user wishes to assume a new MAC label, that user must initiate a new session; the MAC labels of processes cannot be changed. However, a user may be designated as able to change a process label within a specified range. This makes the system more amenable to commercial environments.

38cs691 chow

Controversy Over Bell-LaPadula ModoelControversy Over Bell-LaPadula Modoel

1985 McLean define a †-property which is not secure (allow write down) and show that the basic theorem is not correct.

Definition 5-11. A state (b, m, f, h) satisfies the †-property if and only if, for each subject s c S, the following conditions hold:a. b(s: a) [ ob(s: a) [fc(s) dom fo(o) ] ]b. b(s: w) [ ob(s: w) [fc(s) = fo(o) ] ]c. b(s: r) [ ob(s: r) [fc(s) dom fo(o) ] ]

McLean then proved the analogue to Theorem 5-4: Theorem 5-16. (R, D, W, z0) satisfies the †-property relative to S' S for any secure state z0 if

and only if, for every action (r, d, (b, m, f, h), (b', m', f', h')), W satisfies the following conditions for every s Sa. Every (s, o, p) b - b' satisfies the †-property with respect to Sb. Every (s, o, p) b' that does not satisfy the †-property with respect to S' is not in b.

From this theorem, and from Theorems 5-3 and 5-5, the analogue to the Basic Security Theorem follows.

Theorem 5-17. Basic Security Theorem: (R, D, W, z0) is a secure system if and only if zt is a secure state and W satisfies the conditions of Theorems 5-3, 5-16, and 5-5.

But the system (R, D, W, z0) is clearly not secure. Bell-LaPadula argue that their model assumes the transition introduces no changes that violate

security.

1985 McLean define a †-property which is not secure (allow write down) and show that the basic theorem is not correct.

Definition 5-11. A state (b, m, f, h) satisfies the †-property if and only if, for each subject s c S, the following conditions hold:a. b(s: a) [ ob(s: a) [fc(s) dom fo(o) ] ]b. b(s: w) [ ob(s: w) [fc(s) = fo(o) ] ]c. b(s: r) [ ob(s: r) [fc(s) dom fo(o) ] ]

McLean then proved the analogue to Theorem 5-4: Theorem 5-16. (R, D, W, z0) satisfies the †-property relative to S' S for any secure state z0 if

and only if, for every action (r, d, (b, m, f, h), (b', m', f', h')), W satisfies the following conditions for every s Sa. Every (s, o, p) b - b' satisfies the †-property with respect to Sb. Every (s, o, p) b' that does not satisfy the †-property with respect to S' is not in b.

From this theorem, and from Theorems 5-3 and 5-5, the analogue to the Basic Security Theorem follows.

Theorem 5-17. Basic Security Theorem: (R, D, W, z0) is a secure system if and only if zt is a secure state and W satisfies the conditions of Theorems 5-3, 5-16, and 5-5.

But the system (R, D, W, z0) is clearly not secure. Bell-LaPadula argue that their model assumes the transition introduces no changes that violate

security.

39cs691 chow

McClean’s System ZMcClean’s System Z

In 1987, McClean presented System Z where system transitions can alter any system component, including b, f, m, and h, as long as the new state does not violate security. He demonstrated system satisfies the model but is not a confidentiality security policy.

Bell [64] responded by exploring the fundamental nature of modeling. Newtonia math cannot explain planet movement while Einstein’s theory of general relativity can.

Bell-LaPadula Model is a tool for demonstrating certain properties of rules. Whether the properties of System Z is desirable is an issue the model cannot answer.

Bell-LaPadula Model enforces the principle of strong tranquility. System Z deals with the case of weak tranquility (security level can

change).

In 1987, McClean presented System Z where system transitions can alter any system component, including b, f, m, and h, as long as the new state does not violate security. He demonstrated system satisfies the model but is not a confidentiality security policy.

Bell [64] responded by exploring the fundamental nature of modeling. Newtonia math cannot explain planet movement while Einstein’s theory of general relativity can.

Bell-LaPadula Model is a tool for demonstrating certain properties of rules. Whether the properties of System Z is desirable is an issue the model cannot answer.

Bell-LaPadula Model enforces the principle of strong tranquility. System Z deals with the case of weak tranquility (security level can

change).

40cs691 chow

Problem with Traditional MACProblem with Traditional MAC

Poor support for Data and application integrity (Clark Wilson Integrity model;

Chinese Wall security policy) Separation of duty Least privilege requirement

Require special trusted subject that act outside of the access control model (e.g., lower security level to write down)

Fail to tightly control the relationship between subject and the code it executes. This limits: Limit protection based on function and trustworthiness of the

code. Correctly manage permissions required for execution Minimize the likelihood of malicious code execution

Poor support for Data and application integrity (Clark Wilson Integrity model;

Chinese Wall security policy) Separation of duty Least privilege requirement

Require special trusted subject that act outside of the access control model (e.g., lower security level to write down)

Fail to tightly control the relationship between subject and the code it executes. This limits: Limit protection based on function and trustworthiness of the

code. Correctly manage permissions required for execution Minimize the likelihood of malicious code execution

41cs691 chow

History Security-Enhanced Linux (SELinux)

History Security-Enhanced Linux (SELinux)

National Security Agency (NSA) and Secure Computing Corporation (SCC) provide strong MAC. Flexible support for security policies (no single MAC policy can satisfy

everyone’s security requirements) Cleanly separate the security policy logic from enforcing mechanism Developed DTMach, DTOS (Mach-based prototype) Apply formal method to validate the security properties of the

architecture (High Assurance) Work with Univ. Utah Flux Research Group

integrate the architecture to Fluke research operating system Result: Flask architecture support dynamic security policies.

NSA create SELinux integrate Flash architecture to Linux OS. NAI implements control on procfs and devpts fiel ssytems MITRE/SCC contribute application security policies, modified utility

programs

National Security Agency (NSA) and Secure Computing Corporation (SCC) provide strong MAC. Flexible support for security policies (no single MAC policy can satisfy

everyone’s security requirements) Cleanly separate the security policy logic from enforcing mechanism Developed DTMach, DTOS (Mach-based prototype) Apply formal method to validate the security properties of the

architecture (High Assurance) Work with Univ. Utah Flux Research Group

integrate the architecture to Fluke research operating system Result: Flask architecture support dynamic security policies.

NSA create SELinux integrate Flash architecture to Linux OS. NAI implements control on procfs and devpts fiel ssytems MITRE/SCC contribute application security policies, modified utility

programs

42cs691 chow

SELinuxSELinux

Support Separation policies:

– Enforce legal restriction on data– Establish well-defined user roles– Restrict access to classified data

Containment policies for – Restrict web server access to only authorized data– Minimize damage caused by virues/malicious code

Integrity policies that protect unauthorized modifications to data and applications

Invocation policies that guarantee data is processed as required.

Support Separation policies:

– Enforce legal restriction on data– Establish well-defined user roles– Restrict access to classified data

Containment policies for – Restrict web server access to only authorized data– Minimize damage caused by virues/malicious code

Integrity policies that protect unauthorized modifications to data and applications

Invocation policies that guarantee data is processed as required.