Outline Overview – Mandatory versus discretionary controls – What is a confidentiality model Bell-LaPadula Model – General idea – Description of rules.

Outline• Overview

– Mandatory versus discretionary controls– What is a confidentiality model

• Bell-LaPadula Model– General idea– Description of rules

• Tranquility• Controversy

– †-property– System Z

1

Slide #4-2

Outline

• Policy overview• Policies versus mechanisms• High Level Policies

– E.g., DTEL

• Low Level Policies– E.g., xhost

Slide #4-3

Security Policy

• Policy partitions system states into:– Authorized (secure)

• These are states the system can enter

– Unauthorized (nonsecure)• If the system enters any of these states, it’s a security

violation

• Secure system– Starts in authorized state– Never enters unauthorized state

Slide #4-4

Authorized System States

S1 S2 S3 S4

Slide #4-5

Components of Security Addressed in Policy

• Basic Security Components– Confidentiality– Integrity– Availability

Slide #4-6

Policy Models

• Abstract description of a policy or class of policies• Types of policies

– Military (governmental) security policy• Policy primarily protecting confidentiality

– Commercial security policy• Policy primarily protecting integrity

– Confidentiality policy• Policy protecting only confidentiality

– Integrity policy• Policy protecting only integrity

– Service Level Agreements• Availability agreements

Slide #4-7

Question

• Policy disallows cheating– Includes copying homework, with or without

permission

• CS class has students do homework on computer• Anne forgets to read-protect her homework file• Bill copies it• Who cheated?

– Anne, Bill, or both?

Slide #4-8

Answer Part 1

• Bill cheated– Policy forbids copying homework assignment– Bill did it– System entered unauthorized state (Bill having a copy of

Anne’s assignment)

• If not explicit in computer security policy, certainly implicit– Not credible that a unit of the university allows

something that the university as a whole forbids, unless the unit explicitly says so

Slide #4-9

Answer Part #2

• Anne didn’t protect her homework– Not required by security policy

• She didn’t breach security• If policy said students had to read-protect

homework files, then Anne did breach security– She didn’t do this

Slide #4-10

Mechanisms

• Entity or procedure that enforces some part of the security policy– Access controls (like bits to prevent someone

from reading a homework file)– Disallowing people from bringing CDs and

floppy disks into a computer facility to control what is placed on systems

Slide #4-11

Policy Languages

• Express security policies in a precise way• A continuum of policy languages

– English Policies• May be legally precise. Used as basis for legal action.• May be written imprecisely just to give real users a sense of

the policy• More in later lecture

– High-level languages• Policy constraints expressed abstractly

– Low-level languages• Policy constraints expressed in terms of program options,

input, or specific characteristics of entities on system

Slide #4-12

High-Level Policy Languages

• Constraints expressed independent of enforcement mechanism

• Constraints restrict entities, actions• Constraints expressed unambiguously

– Requires a precise language, usually a mathematical, logical, or programming-like language

• Examples– Java constraint language – described in CS:A&S– DTEL type enforcement language– SAML http://xml.coverpages.org/saml.html– IETF Policy models ftp://ftp.rfc-editor.org/in-notes/rfc3585.txt

Slide #4-13

DTEL – Domain Type Enforcement Language

• Basis: access can be constrained by types• Combines elements of low-level, high-level policy

languages– Implementation-level constructs express constraints in terms of

language types– Constructs do not express arguments or inputs to specific system

commands• Used in Sidewinder firewalls• Details of DTEL in

http://citeseer.ist.psu.edu/cache/papers/cs/16179/http:zSzzSzwww.cs.ubc.cazSzspiderzSzabrodskyzSzdosezSzbadger.95.pdf/badger96domain.pdf

• Type enforcement policies resurfacing in SE Linux

Boebert, Kain 85

Slide #4-14

Example

• Goal: users cannot write to system binaries• Subjects in administrative domain can

– User must authenticate to enter that domain

• Subjects belong to domains:– d_user ordinary users– d_admin administrative users– d_login for login– d_daemon system daemons

Slide #4-15

Types

• Object types:– t_sysbin executable system files– t_readablereadable files– t_writable writable files– t_dte data used by enforcement mechanisms– t_generic data generated from user processes

• For example, treat these as partitions– In practice, files can be readable and writable; ignore

this for the example

Slide #4-16

Domain Representation

• Sequence– First component is list of programs that start in

the domain– Other components describe rights subject in

domain has over objects of a type(crwd->t_writable)

means subject can create, read, write, and list (search) any object of type t_writable

Slide #4-17

d_daemon Domain

domain d_daemon = (/sbin/init),

(crwd->t_writable),

(rd->t_generic, t_readable, t_dte),

(rxd->t_sysbin),

(auto->d_login);

• Compromising subject in d_daemon domain does not enable attacker to alter system files– Subjects here have no write access

• When /sbin/init invokes login program, login program transitions into d_login domain

Slide #4-18

d_admin Domain

domain d_admin =

(/usr/bin/sh, /usr/bin/csh, /usr/bin/ksh),

(crwxd->t_generic),

(crwxd->t_readable, t_writable, t_dte,

t_sysbin),

(sigtstp->d_daemon);

• sigtstp allows subjects to suspend processes in d_daemon domain

• Admin users use a standard command interpreter

Slide #4-19

d_user Domain

domain d_user =

(/usr/bin/sh, /usr/bin/csh, /usr/bin/ksh),

(crwxd->t_generic),

(rxd->t_sysbin),

(crwd->t_writable),

(rd->t_readable, t_dte);

• No auto component as no user commands transition out of it

• Users cannot write to system binaries

Slide #4-20

d_login Domain

domain d_login =

(/usr/bin/login),

(crwd->t_writable),

(rd->t_readable, t_generic, t_dte),

setauth,

(exec->d_user, d_admin);

• Cannot execute anything except the transition– Only /usr/bin/login in this domain

• setauth enables subject to change UID• exec access to d_user, d_admin domains

Slide #4-21

Set Up

initial_domain = d_daemon;

– System starts in d_daemon domainassign -r t_generic /;

assign -r t_writable /usr/var, /dev, /tmp;

assign -r t_readable /etc;

assign -r -s dte_t /dte;

assign -r -s t_sysbin /sbin, /bin,

/usr/bin, /usr/sbin;

– These assign initial types to objects– –r recursively assigns type– –s binds type to name of object (delete it, recreate it, still

of given type)

Slide #4-22

Add Log Type

• Goal: users can’t modify system logs; only subjects in d_admin, new d_log domains can

type t_readable, t_writable, t_sysbin,

t_dte, t_generic, t_log;

• New type t_logdomain d_log =

(/usr/sbin/syslogd),

(crwd->t_log),

(rwd->t_writable),

(rd->t_generic, t_readable);

• New domain d_log

Slide #4-23

Fix Domain and Set-Up

domain d_daemon =

(/sbin/init),

(crwd->t_writable),

(rxd->t_readable),

(rd->t_generic, t_dte, t_sysbin),

(auto->d_login, d_log);

– Subject in d_daemon can invoke logging process– Can log, but not execute anything

assign -r t_log /usr/var/log;

assign t_writable /usr/var/log/wtmp, /usr/var/log/utmp;

– Set type of logs

Slide #4-24

Low-Level Policy Languages

• Set of inputs or arguments to commands– Check or set constraints on system

• Low level of abstraction– Need details of system, commands

• Can think of as specific configuration languages. Generally very closely tied to an application.

• Examples:– Xhost– Unix file system access commands– Tripwire integrity databases– IOS router CLI – Could argue IOS ACL’s are higher level

Slide #4-25

Example: X Window System

• UNIX X11 Windowing System• Access to X11 display controlled by list

– List says what hosts allowed, disallowed accessxhost +groucho -chico

• Connections from host groucho allowed• Connections from host chico not allowed

Slide #4-26

Example: tripwire

• File scanner that reports changes to file system and file attributes– tw.config describes what may change/usr/mab/tripwire +gimnpsu012345678-a

• Check everything but time of last access (“-a”)

– Database holds previous values of attributes

Kim, Spafford 94

Slide #4-27

Example Database Record

/usr/mab/tripwire/README 0 ..../. 100600 45763 1 917 10 33242 .gtPvf .gtPvY .gtPvY 0 .ZD4cc0Wr8i21ZKaI..LUOr3 .0fwo5:hf4e4.8TAqd0V4ubv ?...... ...9b3 1M4GX01xbGIX0oVuGo1h15z3 ?:Y9jfa04rdzM1q:eqt1APgHk ?.Eb9yo.2zkEh1XKovX1:d0wF0kfAvC ?1M4GX01xbGIX2947jdyrior38h15z3 0

• file name, version, bitmask for attributes, mode, inode number, number of links, UID, GID, size, times of creation, last modification, last access, cryptographic checksums

Slide #4-28

Comments

• System administrators not expected to edit database to set attributes properly

• Checking for changes with tripwire is easy– Just run once to create the database, run again to

check

• Checking for conformance to policy is harder– Need to either edit database file, or (better) set system

up to conform to policy, then run tripwire to construct database

Slide #4-29

Key Points

• Policies describe what is allowed• Mechanisms control how policies are

enforced• Spectrum of styles of policy languages• Next time: confidentiality models

Confidentiality

• What is confidentiality?

Confidentiality Policy

• Goal: prevent the unauthorized disclosure of information– Deals with information flow– Integrity incidental

• Example:– Students may not have access to grade files

31

MAC vs DAC• Discretionary Access Control (DAC)

– Access governed by normal users– Owner of a resource can designate permissions– Standard model for Unix, Linux, Windows, etc.– Access control is at the discretion of the user– Implements user’s policy

32

MAC

• Mandatory Access Control (MAC)– Access rules are set system-wide– Normal users cannot violate system-wide rules, even for

resources they “own” (e.g. create)– Implements organizational policy– Usually combined with DAC to add discretion

• Applications– Multi-level military security– Bell-LaPadula Model

Bell-LaPadula Model, Step 1• Security levels arranged in linear ordering

– Top Secret: highest– Secret– Confidential– Unclassified: lowest

• Subjects have security clearance L(s)• Objects have security classification L(o)

34Bell, LaPadula 73

Example

35

objectsubjectsecurity level

Syllabus

Assignments

Assignment Solutions

Grade Files

EveryoneUnclassified

StudentsConfidential

TASecret

NikitaTop Secret

• Nikita can read all files• Students cannot read grade files or assignment solutions• Students not in 461 can only read syllabus

Reading Information• Information flows up, not down

– “Reads up” disallowed, “reads down” allowed• Simple Security Condition (Step 1)

– Subject s can read object o iff, L(o) ≤ L(s) and s has permission to read o

• Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission)

– Sometimes called “no reads up” rule

36

Writing Information• Information flows up, not down

– “Writes up” allowed, “writes down” disallowed• *-Property (Step 1)

– Subject s can write object o iff L(s) ≤ L(o) and s has permission to write o

• Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission)

– Sometimes called “no writes down” rule

37

Basic Security Theorem, Step 1• If a system is initially in a secure state, and

every transition of the system satisfies the simple security condition (step 1), and the *-property (step 1), then every state of the system is secure– Proof: induction on the number of transitions

• Meaning of “secure” in axiomatic

38

Need to Know• Consider the notion of “need-to-know”• Example:

– Two sections for a class, with two TAs– TA1 doesn’t need to know grades for section 2, and vice versa– Cannot introduce linear ordering between TAs to enforce this

• Military applications:– Different operations– Someone cleared for Top Secret on operation X may not need to

know even unclassified documents on operation Y

39

Bell-LaPadula, Step 2

• Expand notion of security level to include categories (also called compartments)

• Security level is (clearance, category set)• Examples

– ( Top Secret, { NUC, EUR, ASI } )– ( Confidential, { EUR, ASI } )– ( Secret, { NUC, ASI } )

Levels and Lattices• (A, C) dom (A, C) iff A ≤ A and C C• Examples

– (Top Secret, {NUC, ASI}) dom (Secret, {NUC})– (Secret, {NUC, EUR}) dom (Confidential,{NUC, EUR})– (Top Secret, {NUC}) dom (Confidential, {EUR})– (Secret, {NUC}) dom (Confidential,{NUC, EUR})

• Let C be set of classifications, K set of categories. Set of security levels L = C K, dom form lattice– Partially ordered set– Any pair of elements

• Has a greatest lower bound• Has a least upper bound

41

Example Lattice

42

ASI,NUC ASI,EUR

ASIEUR

NUC

NUC,EUR

ASI,NUC,EUR

Subset Lattice

43

TS:NUC,EUR

TS:NUC,ASITS:NUC

S:NUC

C:NUC,EUR

C:EUR

U:

TS: ASI,NUC,EUR

Levels and Ordering• Security levels partially ordered

– Any pair of security levels may (or may not) be related by dom

• “dominates” serves the role of “greater than” in step 1– “greater than” is a total ordering, though

44

Reading Information• Information flows up, not down

– “Reads up” disallowed, “reads down” allowed• Simple Security Condition (Step 2)

– Subject s can read object o iff L(s) dom L(o) and s has permission to read o

• Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission)

– Sometimes called “no reads up” rule

45

Writing Information• Information flows up, not down

– “Writes up” allowed, “writes down” disallowed• *-Property (Step 2)

– Subject s can write object o iff L(o) dom L(s) and s has permission to write o

• Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission)

– Sometimes called “no writes down” rule

46

Basic Security Theorem, Step 2• If a system is initially in a secure state, and

every transition of the system satisfies the simple security condition (step 2), and the *-property (step 2), then every state of the system is secure– Proof: induct on the number of transitions– In actual Basic Security Theorem, discretionary

access control treated as third property, and simple security property and *-property phrased to eliminate discretionary part of the definitions — but simpler to express the way done here.

47

Problem• One-way flow of information may be too

restrictive• E.g. Colonel with Top Secret clearance cannot

write to anywhere a Major with Secret clearance can read– Is this a problem?

48

Solution• Define maximum, current levels for subjects

– maxlevel(s) dom curlevel(s)• Example

– Treat Major as an object (Colonel is writing to him/her)– Colonel has maxlevel (Secret, { NUC, EUR })– Colonel sets curlevel to (Secret, { EUR })– Now L(Major) dom curlevel(Colonel)

• Colonel can write to Major without violating “no writes down”– Does L(s) mean curlevel(s) or maxlevel(s)?

• Formally, we need a more precise notation

49

Adjustments to “write up”• Write permission usually allows read/write

access to object– So both simple security condition and *-property

apply– S dom O and O dom S means S=O

• BLP discuss append as a “pure” write so “write up” still applies

50

Principle of Tranquility

• Raising object’s security level– Information once available to some subjects is no longer

available– Usually assume information has already been accessed, so

this does nothing• Lowering object’s security level

– The declassification problem– Essentially, a “write down” violating *-property– Solution: define set of trusted subjects that sanitize or

remove sensitive information before security level lowered

51

Types of Tranquility

• Strong Tranquility– The clearances of subjects, and the classifications

of objects, do not change during the lifetime of the system

• Weak Tranquility– The clearances of subjects, and the classifications

of objects change in accordance with a specified policy.

52

Example• DG/UX System

– Only a trusted user (security administrator) can lower object’s security level

– In general, process MAC labels cannot change• If a user wants a new MAC label, needs to initiate new

process• Cumbersome, so user can be designated as able to

change process MAC label within a specified range

• Other systems allow multiple labeled windows to address users operating a multiple levels

53

Controversy• McLean:

– “value of the BST is much overrated since there is a great deal more to security than it captures. Further, what is captured by the BST is so trivial that it is hard to imagine a realistic security model for which it does not hold.”

54McLean 85

Definition of Security• BLP define security in terms of *-property• State (b, m, f, h) satisfies the *-property iff for each s S

the following hold:1. b(s: a) ≠ [o b(s: a) [ fc(o) dom fo(s) ] ]

2. b(s: w) ≠ [o b(s: w) [ fo(o) = fc(s) ] ]

3. b(s: r) ≠ [o b(s: r) [ fc(s) dom fo(o) ] ]

55

Redefinition: †-property

• State (b, m, f, h) satisfies the †-property iff for each s S the following hold:1. b(s: a) ≠ [o b(s: a) [ fc(s) dom fo(o) ] ]

2. b(s: w) ≠ [o b(s: w) [ fo(o) = fc(s) ] ]

3. b(s: r) ≠ [o b(s: r) [ fc(s) dom fo(o) ] ]

• Idea: for writing, subject dominates object; for reading, subject also dominates object

• Differs from *-property in that the mandatory condition for writing is reversed– For *-property, it’s object dominates subject

AnaloguesThe following two theorems can be proved (R, D, W, z0) satisfies the †-property relative to S S for any

secure state z0 iff for every action (r, d, (b, m, f, h), (b, m, f, h)), W satisfies the following for every s S´– Every (s, o, p) b – b satisfies the †-property relative to S– Every (s, o, p) b that does not satisfy the †-property relative to S is

not in b (R, D, W, z0) is a “secure” system if z0 is a secure state and W

satisfies the conditions for the simple security condition, the †-property, and the ds-property.

57

Problem• This system is clearly non-secure!

– Information flows from higher to lower because of the †-property

58

Key Points• Confidentiality models restrict flow of

information• Bell-LaPadula models multilevel security

– Cornerstone of much work in computer security

• Definition of security as important as model for enforcing it

61