Access Control Theory => Practice Nicolas T. Courtois - University College London.

74
Access Control Theory => Practice Nicolas T. Courtois - University College London

Transcript of Access Control Theory => Practice Nicolas T. Courtois - University College London.

Access ControlTheory => Practice

Nicolas T. Courtois - University College London

CompSec COMPGA01

Nicolas T. Courtois, January 20092

Roadmap• Policies and Mechanisms• Set models, • Maths: Relations, Bounds, Lattices• Reference Monitor model• DAC, Matrix model• DAC in practical OS (slides part 04)

Reading

Nicolas T. Courtois, January 20093

Home reading

• Security Policies: Section 2.2.1 discussed in the context of management!

• Partial orderings, Lattices: Section 5.8 • Reference Monitor: Section 5.2. + page 88

– Deeper study outside of scope of this course: pages 89-90.

• DAC, ownership, matrices, basic rights; Sections 5.3. – 5.5.

CompSec COMPGA01

Nicolas T. Courtois, January 20094

Preface

CompSec COMPGA01

Nicolas T. Courtois, January 20095

Can We Help?

insecure rubbish!

Science vs.

CompSec COMPGA01

Nicolas T. Courtois, January 20096

History• There is a substantial amount of theory about access

control. – When UNIX systems were developed, more or less at the

same time, researchers have tried to formalize what access control should be doing…

– Influence of pure mathematicians on the topic…

• Designers of OS, HTTP servers, database systems etc. have developed highly complex systems, learning from this research, and/or from hacker attacks, Trojans etc.

• Windows NT and now commercial security/firewall packages (with lots of detailed controls), and Vista etc. were developed much later. – and with additional complexity that does not exist in Unix.

CompSec COMPGA01

Nicolas T. Courtois, January 20097

Is There a Need For Access Control ?

The problem of access control remains largely unsolved. And seems almost unsolvable, – OS+add-on security all-in-one security packages

will • either decide everything for you, • or leave the customer with choices that nobody

understands

CompSec COMPGA01

Nicolas T. Courtois, January 20098

Policies

CompSec COMPGA01

Nicolas T. Courtois, January 20099

Security Policy:

Meaning we want to use:

Policy, is what we want.

How things should be.

CompSec COMPGA01

Nicolas T. Courtois, January 200910

A Security Policy:

Short, succinct statement. High-level.Describes what is and what is not allowed.

Security and protection requirements, rules, and goals.

It defines what it means to be “secure” for a system or organisation/entity.

Here, it usually means a set of requirements.

Here, it means usually a set of behaviour rules to obey.

CompSec COMPGA01

Nicolas T. Courtois, January 200911

W7 has a “Local Security Policy”Can be edited

CompSec COMPGA01

Nicolas T. Courtois, January 200912

Mechanisms

CompSec COMPGA01

Nicolas T. Courtois, January 200913

Policies and Mechanisms

Mechanisms are there to enforce policies.• various sorts of mechanisms, HW, SW, crypto, and

combinations…

• A policy can be implemented in several different ways, relying on different mechanisms.

CompSec COMPGA01

Nicolas T. Courtois, January 200914

Formalization: Sets

CompSec COMPGA01

Nicolas T. Courtois, January 200915

A Security Policy – Abstract view

Describes what is and what is not allowed.

Can be mathematically formalized as follows:

All possible “states of the world” P in a system are partitioned into allowed states Q P and non-allowed states P-Q P.

Beware: in this formulation, these are not merely states of a PC. They need to encompass the user and all the entities in involved. Example: user A is reading the file f at 10h should define a distinct subset of the universe of possible outcomes.

A Security Mechanism =>May restrict the system to a subset of states R P.

CompSec COMPGA01

Nicolas T. Courtois, January 200916

Secure vs. Precise vs. BroadStates allowed by the policy Q P.

States allowed by the mechanism R P.

Def. [Bishop]A mechanism is secure iff R Q.

All that ever happens is acceptable, but certain things could be forbidden for no reason.

A mechanism is precise iff R = Q. All that can ever happen is exactly what is allowed.

A mechanism is broad iff R Q – (could be called insecure)Allowing of unwanted or “insecure” states.

CompSec COMPGA01

Nicolas T. Courtois, January 200917

More Maths

CompSec COMPGA01

Nicolas T. Courtois, January 200918

RelationsLet A be a set. We call relation any subset R AxA.

We write things such as:

a R b which reads

a is “in relation R” to b

set of all ordered pairs a_1,a2

CompSec COMPGA01

Nicolas T. Courtois, January 200919

Example of a Relation

Let a,b NIDefinition: a | b

iff x NI such that ax=b.

CompSec COMPGA01

Nicolas T. Courtois, January 200920

Relations

Sub-categories:• equivalence relations, • order relations (orderings),• etc.

CompSec COMPGA01

Nicolas T. Courtois, January 200921

Order RelationsOrder: 1. Reflexive: a a 2. Antisymmetric: if a b and b a then a = b.3. Transitive a b and b c implies a c.

Partial ordering: For any couple a,b we have either

a b or b a or neither – when we say that “a and b are

unrelated”.

Total ordering (= linear order = simple order = chain): 4. For any couple a,b we have either

a b or b a.all pairs are related = mutually comparable

CompSec COMPGA01

Nicolas T. Courtois, January 200922

POSET = Partially Ordered Set

A set A and an order relation . Poset is the couple (A, ).

Maths view: we write formulas on the board and we use axioms 123

on the last slide to prove theorems.

Pragmatic computational functional view of a relation: we have

objects a Adata type A2-ary function called : AxA {True, False}.

CompSec COMPGA01

Nicolas T. Courtois, January 200923

Example of a POSET

Let a,b NIDefinition: a | b means x such that ax=b.

(NI, |) is a poset• Reflexive: a | a • Antisymmetric: if a | b and b | a then a = b.• Transitive a | b and b | c implies a | c.

Proof:

But not a total order: Prove it:

CompSec COMPGA01

Nicolas T. Courtois, January 200924

Example 2 of a POSET

Let be an alphabet Let * be the set of all strings over . Define Prefix(a,b) formally

CompSec COMPGA01

Nicolas T. Courtois, January 200925

Example 2 of a POSET

Let be an alphabet Let * be the set of all strings over . Def: Prefix(a,b) iff c s.t. a||c=b

Theorem: (*, Prefix) is a poset. Proof?

CompSec COMPGA01

Nicolas T. Courtois, January 200926

Example 2 of a POSET

Let be an alphabet Let * be the set of all strings over . Def: Prefix(a,b) iff c in * s.t. a||c=b

Theorem: (*, Prefix) is a poset.Relation Prefix is a partial ordering.

CompSec COMPGA01

Nicolas T. Courtois, January 200927

Example 2 of a POSET

Let be an alphabet Let * be the set of all strings over . Def: Prefix(a,b) iff c in *s.t. a||c=b

Theorem: (*, Prefix) is a poset.Relation Prefix is a partial ordering.• R• A• T

CompSec COMPGA01

Nicolas T. Courtois, January 200928

Example 2 of a POSETLet be an alphabet Let * be the set of all strings over . Def: Prefix(a,b) iff c in * s.t. a||c=b

Theorem: (*, Prefix) is a poset.Relation Prefix is a partial ordering.• Reflexive: a is a prefix of a • Anti-symmetric:

if a is a prefix of b and b is a prefix of a then a = b.

• Transitive a is a prefix of b and b is a prefix of c, it implies a is a prefix of c.

But not a total order if there are at least 2 symbols: Prove it.

CompSec COMPGA01

Nicolas T. Courtois, January 200929

Applications

Order relations are useful in formalising and analysing security…

CompSec COMPGA01

Nicolas T. Courtois, January 200930

Bounds

Exist for both total and partial orders.Total orders are simple in sense they are “one-

dimensional”. Like a straight line…

Partial orders describe much more complex situations…

CompSec COMPGA01

Nicolas T. Courtois, January 200931

Bounds

Definition:u is an upper bound for a and b iff

au and bu.

Definition:v is an lower bound for a and b iff

va and vb.

a b

u

v

CompSec COMPGA01

Nicolas T. Courtois, January 200932

LUB = Least Upper Bound = Supremum = Sup = Join

Definition:Definition:u is an upper bound for a and b iffu is an upper bound for a and b iff

aau and bu and bu.u.Definition:Let U be the set of all upper bounds for a and b. Let u be the smallest element in U,

which means x U we have ux.Then u is called the Least Upper Bound of a and b.We write:

u=a b

and say “least upper bound for a and b” or “a Vee b”In LaTeX \vee

a b

xy

u

CompSec COMPGA01

Nicolas T. Courtois, January 200933

LUB = Least Upper Bound = Supremum = Sup = Join

a b

and we have the dual concept:

GLB = Greatest Lower Bound = Infimum = Inf = Meet

a b

CompSec COMPGA01

Nicolas T. Courtois, January 200934

LUB = Least Upper Bound = Supremum = Sup = Join

a b

and we have the dual concept:

GLB = Greatest Lower Bound = Infimum = Inf = Meet

a bdefined in the same way…

BTW. we say “greatest lower bound for a and b” or “a Wedge b”

In LaTeX \wedge

CompSec COMPGA01

Nicolas T. Courtois, January 200935

Funny Example Claim 1: NI, is a total ordering.Proof: check 123+total

Claim 2: 1 is the biggest element of NI.Proof:

Let u be the biggest integer.#: Assume u>1 (which definition means u1 AND u1).It follows that u2>u.It follows that u2 is even bigger, so u is not the biggest integer.So our Assumption # was wrong.So u1.So u=1 (0 is smaller and must be excluded).

CompSec COMPGA01

Nicolas T. Courtois, January 200936

Important

Bounds do NOT have to exist.

Least upper bounds don’t have to exist either.

CompSec COMPGA01

Nicolas T. Courtois, January 200937

Latticeswill be on the examwill be on the exam

CompSec COMPGA01

Nicolas T. Courtois, January 200938

LatticesDefinition:An ordered set S, Is called a lattice if:

a, b the LUB a b exists.

a, b the GLB a b exists.

More about lattices later in part 02c!!!!!!!

CompSec COMPGA01

Nicolas T. Courtois, January 200939

Example: “Hasse Diagram”

Top Secret, {army, nuclear}

Top Secret, {army}

Top Secret, {nuclear} Secret, {army, nuclear}

Top Secret, {} Secret, {army} Secret, {nuclear}

Secret, {}

CompSec COMPGA01

Nicolas T. Courtois, January 200940

File Access Control

CompSec COMPGA01

Nicolas T. Courtois, January 200941

Example of a Security PolicyNo user should be able to access

other user’s files.Benefits:• Accountability• Trace-ability• Confidentiality, Privacy

Two methods to implement this, can be combined:1. Follow the people:

authentication, authorization.

2. Follow the data: information flow control.

CompSec COMPGA01

Nicolas T. Courtois, January 200942

Users, Subjects, Principals

Meprocess

running as me

create through authentication and

authorization

ownership

User, Principal

Subject

our book says principals == uniquely and reliably identified human users

HOWEVER…can make a distinction:

CompSec COMPGA01

Nicolas T. Courtois, January 200943

Distinction Users vs. PrincipalsOne to Many.

Meprocess

running as login2

create through authentication and

authorization

ownership

User

login2

login1Principal

= def: Unit of Access Controland Authorization

Subject

similar in Java Principal == human readable name

CompSec COMPGA01

Nicolas T. Courtois, January 200944

Subjects and Objects

Meprocess

running as me/login2

access through authorization

access controloccurs at 2 moments!

User, Principal, Subject

Object

resource?

policy

referencemonitor

In Unix processes are both subjects and objects, we can execute operations on processes: kill, suspend, resume..

process2

CompSec COMPGA01

Nicolas T. Courtois, January 200945

Reference Monitor

Def: (in OS and software security)(in OS and software security)

module that controls all software access to data objects or devices.

exists since Windows NT (XP,Vista).

resourceuser

process

referencemonitor

access request

policy

?

CompSec COMPGA01

Nicolas T. Courtois, January 200946

Reference Monitor

Must be:1. tamperproof, 2. always-invoked = non-bypassable =

a.k.a. complete mediation3. economical, simple

– small enough to be build in a rigorous way, • and fully tested and analysed

Windows: exists since Windows NT.

CompSec COMPGA01

Nicolas T. Courtois, January 200947

**Optional Reading:

• At which level/place to implement the Reference Monitor? – Section 6.1.1.

More than reference monitor:

• TCB = Trusted Computing Base or Security Kernel (very closely related concepts): – like all the protections inside the computer

combined together…– combination of hardware and software– fundamental “low layers” of a secure OS…

CompSec COMPGA01

Nicolas T. Courtois, January 200948

Technical Difficulties

• Residue Channels– Inadvertent or built-in duplication/storage of

information.• need to actively clean disk sectors, memory, CPU

cache etc.

• Covert Channels– information is leaking

• intentional or not (side channels).

CompSec COMPGA01

Nicolas T. Courtois, January 200949

Access Control Models

Formally and mathematically define the access control method. It should be:

• Complete– Encompass all our security desiderata.

• Consistent.– Free of contradictions.

CompSec COMPGA01

Nicolas T. Courtois, January 200950

Access Control ModelsBenefits:

We can formally prove security properties of a system. Derived from basic premises.

Nice split between conceptual and practical security: • Prove that model is “secure”.• And that the implementation is correct.

Allows to claim that security is achieved. • And if it isn’t, we should be able to blame EITHER the model

OR the implementation, without any ambiguity.

CompSec COMPGA01

Nicolas T. Courtois, January 200951

3 Main Paradigms of Access Control

Discretionary Access Control (DAC)• Owners decide about rules, at their discretion,

can pass rights on others

Mandatory Access Control (MAC)• System-wide policy, possibly denying users

full control over the access to resources they created

Role-Based Access Control (RBAC)

frequently combined

CompSec COMPGA01

Nicolas T. Courtois, January 200952

Two levelsIn most policies,

• except in pure Mandatory AC policies.

Two main levels:• Access Control Policy.

– who can access the resources?

• Administrative Policy.– who can specify rules and authorizations?

And big problem: things change. Ownership can be changed. Permissions can be changed.

CompSec COMPGA01

Nicolas T. Courtois, January 200953

Discretionary Access Control

CompSec COMPGA01

Nicolas T. Courtois, January 200954

What is DAC?DAC policies are a family of access control policies.

1. They enforce the access to files on the basis of• identity of the requestors• explicit access rules:

2. In addition, files have owners• “Discretionary” means:

the owner can grant/revoke rights for others

CompSec COMPGA01

Nicolas T. Courtois, January 200955

Matrix Paradigm [Lampson,Graham-Denning, Harrison-Ruzzo-Ullmann]

A way to describe mathematically access conditions

• A set S of Subjects (Principals).• A set O of Objects (e.g. files).• A set A of Operations. Example: A={read,append,write}.

An access control matrix.

M=(Mso) sS oOWhere each entry MsoA.

CompSec COMPGA01

Nicolas T. Courtois, January 200956

Matrix - ExampleExample:

S={System,Admin,Bob}.

O={exe,doc}.

A={read,write,exec,delete}.

M=

m.exe a.doc

System {x,r,w,d} {r,w,d}

Admin {x,w,d} {w,r,d}

Bob {x} {r,w}

rights

Objects

Subjects

CompSec COMPGA01

Nicolas T. Courtois, January 200957

Examples: Standard File Systems

CompSec COMPGA01

Nicolas T. Courtois, January 200958

Simple Example - UnixS={Process1; User1}.

O={file2; directory3; process5; device6}.

A={r, w, exe}.

ls -l => -rwx-r-x—-the famous “9 bits”: user group other

CompSec COMPGA01

Nicolas T. Courtois, January 200959

Windows NTIn comparison - excessively complex, more recent.

Required: NTFS, the Microsoft file system designed to work in multi-user environments. Win NT/XP and later.

CompSec COMPGA01

Nicolas T. Courtois, January 200960

DAC in Practice

CompSec COMPGA01

Nicolas T. Courtois, January 200961

Matrices - ImplementationMatrix storage: waste of space, not very practical.• Authorization table – sparse matrix kind• Capabilities - rows• Access Control Lists (ACL) - columns

CompSec COMPGA01

Nicolas T. Courtois, January 200962

Matrices - Authorization Tables

• Authorization tables,– Commonly used in relational DBMS– Store table of non-null triples (s,o,a).

CompSec COMPGA01

Nicolas T. Courtois, January 200963

Matrices – ACLs and Capabilities

• Access Control Lists (ACL)– store M by columns,

– together with each object,

• Capabilities – store M by rows.

– for each user store his capabilities,

most popular, Unix, Win

CompSec COMPGA01

Nicolas T. Courtois, January 200964

In theory…ACLs are widely used (Linux, Windows, etc.)

In theory, Access Control Lists (ACLs) and capabilities represent the same thing.

So if we implement ACLs, no need for capabilities.

In practice however, they lead to very different systems.

CompSec COMPGA01

Nicolas T. Courtois, January 200965

Managing Permissions• With ACLs, the power to edit the authorities

(permissions) is aggregated by resource.• naturally compatible with Discretionary Access

Control, owners

• With capabilities it will be rather aggregated by Subjects.

CompSec COMPGA01

Nicolas T. Courtois, January 200966

AuthenticationACL's:

– store rights together with each object,

– requires a form of authentication of subjects at the moment of access

Capabilities:

– for each user store his capabilities,

– does not require authentication of subjects: • capabilities are explicit rights in a form of a token, that represents the user’s capabilities.

– but require some form of unforgeability

+ maybe some form control of propagation of capabilities…

• token:

– now the hacker may try to copy this token from one user to another. So it should be cryptographically signed, and depend on the user’s ID! (some people encrypt capabilities too).

CompSec COMPGA01

Nicolas T. Courtois, January 200967

Fast Access, Review, revocation• ACL's provide faster access, review and

revocation on a per-object basis• but if we want to revoke permissions for a particular user, we have to search a

whole hard drive…

• capabilities provide faster access and review and revocation on a per-subject basis

CompSec COMPGA01

Nicolas T. Courtois, January 200968

Least Privilege

•capabilities are better in this respect,

•especially for dynamic short-lived subjects created for specific tasks

CompSec COMPGA01

Nicolas T. Courtois, January 200969

Ambient Authority

= def = Making a request that only specifies • the names of the object(s) involved and • the operation to be performed on them, is enough for a permitted action to succeed. dominant method today

(POSIX ACLs, Windows as well).

With capability-based security programs receive also permissions as they might receive data. – this allows programs to determine where the

permissions came from.

CompSec COMPGA01

Nicolas T. Courtois, January 200970

The Confused Deputy Problem

Definition: The confused deputy problem occurs when one process tricks another process to do an action he doesn’t have permissions to do.

Example 1: A compiler is given a permission to write in a directory. The user compiles a program and specifies some very special filename for the output log. So he can overwrite some files he should not have access to.

CompSec COMPGA01

Nicolas T. Courtois, January 200971

Composition of Policies

CompSec COMPGA01

Nicolas T. Courtois, January 200972

Composition of PoliciesCombine all the benefits of DAC and MAC?Windows and Unix do it.

The simplest method:

(works like a logical AND)– allow an operation only if all policies implemented

allow it.

CompSec COMPGA01

Nicolas T. Courtois, January 200973

Quiz

CompSec COMPGA01

Nicolas T. Courtois, January 200974

QuizWhat is a• A security policy for an organisation? For a system?• A “broad” security mechanism? opposite of it?• An order relation (RAT)• Give an example of a totally ordered set.• Give an example of an order that is NOT a total order. • GLB? The dual notion?• Lattice?