1 2 3 4 5 6 subject cannot change current levels 7 Objections - - PowerPoint PPT Presentation

1 2 3 4 5 6 subject cannot change current levels
SMART_READER_LITE
LIVE PREVIEW

1 2 3 4 5 6 subject cannot change current levels 7 Objections - - PowerPoint PPT Presentation

1 2 3 4 5 6 subject cannot change current levels 7 Objections to BLP (1) Some processes, such as memory management, need to read and write at all levels Fix: put them in the trusted computing base Consequence: once you put


slide-1
SLIDE 1

1

slide-2
SLIDE 2

2

slide-3
SLIDE 3

3

slide-4
SLIDE 4

4

slide-5
SLIDE 5

5

slide-6
SLIDE 6

6

slide-7
SLIDE 7

7

  • subject cannot change current levels
slide-8
SLIDE 8

Objections to BLP (1)

  • Some processes, such as memory

management, need to read and write at all levels

  • Fix: put them in the trusted computing base
  • Consequence: once you put in all the stuff a

real system needs (backup, recovery, comms, …) the TCB is no longer small enough to be easily verifiable

8

Ross Anderson

slide-9
SLIDE 9

Objections to BLP(2)

  • John MacLean’s “System Z”: as BLP but lets users
  • req. temporary declassification of any file
  • Fix: add tranquility principles

– Strong tranquility: labels never change – Weak tranquility: they don’t change in such a way as to break the security policy

  • Usual choice: weak tranquility using the “high

watermark principle” – a process acquires the highest label of any resource it’s touched

  • Problem: have to rewrite apps (e.g. license server)

9

Ross Anderson

slide-10
SLIDE 10

Objections to BLP (3)

  • High can’t acknowledge receipt from Low
  • This blind write-up is often inconvenient: information

vanishes into a black hole

  • Option 1: accept this and engineer for it (Morris

theory) – CIA usenet feed

  • Option 2: allow acks, but be aware that they might

be used by High to signal to Low

  • Use some combination of software trust and covert

channel elimination

10

Ross Anderson

slide-11
SLIDE 11

Variants of BLP

  • Noninterference: no input by High can affect

what Low can see. So whatever trace there is for High input X, there’s a trace with High input Ø that looks the same to Low (Goguen & Messeguer 1982)

  • Nondeducibility: weakens this so that Low is

allowed to see High data, just not to understand it – e.g. a LAN where Low can see encrypted High packets going past (Sutherland 1986)

11

Ross Anderson

slide-12
SLIDE 12

Variants on Bell-LaPadula (2)

  • Biba integrity model: deals with integrity

rather than confidentiality. It’s “BLP upside down” – high integrity data mustn’t be contaminated with lower integrity stuff

  • Domain and Type Enforcement (DTE): subjects

are in domains, objects have types

  • Role-Based Access Control (RBAC): current

fashionable policy framework

Ross Anderson

slide-13
SLIDE 13

The Cascade Problem

Ross Anderson

Connecting the two -- issue

slide-14
SLIDE 14
  • Consider a simple device that accepts two

High inputs H1 and H2, multiplexes them, encrypts them by xor’ing them with a one- time pad, outputs the other copy of the pad

  • n H3, and outputs the ciphertext, which

being encrypted with a cipher system giving perfect secrecy, is considered to be Low (output L)

14

slide-15
SLIDE 15
  • In isolation, this device is provably secure. But

if feedback is permitted, then the output from H3 can be fed back into H2, with the result that the high input H1 now appears at the low

  • utput L.

15

slide-16
SLIDE 16

Composability

  • Systems can become insecure when

interconnected, or when feedback is added

Ross Anderson

slide-17
SLIDE 17

Composability

  • So nondeducibility doesn’t compose
  • Neither does noninterference
  • Many things can go wrong – clash of timing

mechanisms, interaction of ciphers, interaction of protocols

  • Practical problem: lack of good security interface

definitions (Keep in mind API failures)

  • Labels can depend on data volume, or even be non-

monotone (e.g. Secret laser gyro in a Restricted inertial navigation set)

Ross Anderson

slide-18
SLIDE 18

Consistency

  • US approach (polyinstantiation):
  • UK approach (don’t tell low users):

Cargo Destination Secret Missiles Iran Unclassified Spares Cyprus Cargo Destination Secret Missiles Iran Restricted Classified Classified

Ross Anderson

slide-19
SLIDE 19

Downgrading

  • A related problem to the covert channel is how to

downgrade information

  • Analysts routinely produce Secret briefings based on

Top Secret intelligence, by manual paraphrasing

  • Also, some objects are downgraded as a matter of

deliberate policy – an act by a trusted subject

  • For example, a Top Secret satellite image is to be

declassified and released to the press

Ross Anderson

slide-20
SLIDE 20

Examples of MLS Systems

  • SCOMP – Honeywell variant of Multics,

launched 1983. Four protection rings, minimal kernel, formally verified hardware and

  • software. Became the XTS-300
  • Used in military mail guards
  • Motivated the ‘Orange Book’ – the Trusted

Computer System Evaluation Criteria

  • First system rated A1 under Orange Book

Ross Anderson

slide-21
SLIDE 21

Examples of MLS Systems (2)

  • Blacker – series of encryption devices designed to

prevent leakage from “red” to “black”. Very hard to accommodate administrative traffic in MLS!

  • Compartmented Mode Workstations (CMWs) – used

by analysts who read Top Secret intelligence material and produce briefings at Secret or below for troops, politicians … Mechanisms allow cut-and-paste from L  H, L  L and H  H but not H  L

Ross Anderson

slide-22
SLIDE 22

Examples of MLS Systems (3)

22

slide-23
SLIDE 23

Examples of MLS Systems (4)

  • LITS – RAF Logistics IT System – a project to control

stores at 80 bases in 12 countries. Most stores ‘Restricted’, rest ‘Secret’, so two databases connected by a pump

  • Other application-level rules, e.g. ‘don’t put

explosives and detonators in the same truck’

  • Eventual solution: almost all stuff at one level, handle

nukes differently

Ross Anderson

slide-24
SLIDE 24

Examples of MLS Systems (5)

  • DERA’s ‘Purple Penelope’ was an attempt to relax

MLS to accountability for lower levels of stuff

  • Driver: people determined to use Office
  • Solution: wrapper around Windows that tracks

current level using high watermark

  • Downgrading allowed, but system forces

authentication and audit

  • Now called ‘Sybard Suite’

Ross Anderson

slide-25
SLIDE 25

DG/UX System (Cf. Matt Bishop)

  • Provides mandatory access controls

– MAC label identifies security level – Default labels, but can define others

  • Initially

– Subjects assigned MAC label of parent

  • Initial label assigned to user, kept in Authorization and

Authentication database

– Object assigned label at creation

  • Explicit labels stored as part of attributes
  • Implicit labels determined from parent directory
slide-26
SLIDE 26

MAC Regions

Administrati ve Region A&A database , audit User data and applications User Region Hierarchy levels VP–1 VP–2 VP–3 VP–4 Site executables Trusted data Executables not part of the TCB Reserved for future use Virus Prevention Re gion Categories VP–5 Executables part of the TCB IMPL_HI is “maximum” (least upper bound) of all levels IMPL_LO is “minimum” (greatest lower bound) of all levels

slide-27
SLIDE 27

Directory Problem

  • Process p at MAC_A tries to create file /tmp/x
  • /tmp/x exists but has MAC label MAC_B

– Assume MAC_B dom MAC_A

  • Create fails

– Now p knows a file named x with a higher label exists

  • Fix: only programs with same MAC label as directory

can create files in the directory

– Now compilation won’t work

slide-28
SLIDE 28

Multilevel Directory

  • Directory with a set of subdirectories, one per label

– Not normally visible to user – p creating /tmp/x actually creates /tmp/d/x where d is directory corresponding to MAC_A – All p’s references to /tmp go to /tmp/d

slide-29
SLIDE 29

Object Labels

  • Requirement: every file system object must

have MAC label

  • 1. Roots of file systems have explicit MAC

labels

  • If mounted file system has no label, it gets

label of mount point

  • 2. Object with implicit MAC label inherits label
  • f parent
slide-30
SLIDE 30

Object Labels

  • Problem: object has two names

– /x/y/z, /a/b/c refer to same object – y has explicit label IMPL_HI – b has explicit label IMPL_B

  • Case 1: hard link created while file system on

DG/UX system, so … 3. Creating hard link requires explicit label

  • If implicit, label made explicit
  • Moving a file makes label explicit
slide-31
SLIDE 31

Object Labels

  • Case 2: hard link exists when file system mounted

– No objects on paths have explicit labels: paths have same implicit labels – An object on path acquires an explicit label: implicit label

  • f child must be preserved

so … 4. Change to directory label makes child labels explicit before the change

slide-32
SLIDE 32

Object Labels

  • Symbolic links are files, and treated as such,

so …

  • 5. When resolving symbolic link, label of object

is label of target of the link

  • System needs access to the symbolic link itself
slide-33
SLIDE 33

Exercise I -- DAC

Reading Suggestion: Section 7.3 of Fred Schneider, “ Access Control” Exercise : 7.1, 7.2, 7.3, 7.4, 7.6, 7.10, 7.13, 7.16 ( 9 problems) Submission date: 20 Feb 2017

slide-34
SLIDE 34

The Biba Model

  • Contrary to Bell-LaPadula model, in Biba model information

can only flow from a higher integrity class to a lower integrity class.

  • L is a linearly ordered set of integrity levels
  • C is a lattice of integrity categories
  • Integrity levels form a linear lattice in which each level

represents the classification of integrity of information an

  • bject can contain or the clearance of a subject for modifying

an object.

  • Integrity categories form a subset lattice and are used to

enforce the need-to-have principle.

  • The lattice of security classes is L × C.
slide-35
SLIDE 35

The Biba Model contd…

  • Security with respect to integrity in the Biba model is

described by the following two axioms:

  • Simple security property: Writing information to an object o

by a subject s requires that SC(s) dominates SC(o) (“no write up”).

  • The*-property: Reading information from an object o by a

subject s requires that SC(o) dominates SC(s) ( “no read down”).

slide-36
SLIDE 36

Multilevel Integrity (2)

  • Big potential application – control systems
  • E.g. in future “smart grid”

– Safety: highest integrity level – Control: next level – Monitoring (SCADA): third level – Enterprise apps (e.g. billing): fourth level

  • Complexity: prefer not to operate plant if SCADA

system down (though you could)

  • So a worm attack on SCADA can close an asset

Ross Anderson

slide-37
SLIDE 37

Multilevel Integrity (3)

  • LOMAC was an experimental Linux system with

system files at High, network at Low

  • A program that read traffic was downgraded
  • Vista adopted this – marks objects Low, Medium,

High or System, and has default policy of NoWriteUp

  • Critical stuff is System, most other stuff is Medium, IE

is Low

  • Could in theory provide good protection – in

practice, UAC (User account control in Windows) trains people to override it!

Ross Anderson

slide-38
SLIDE 38

Comparison of two Multilevel Models

  • The Bell-LaPadula Model is concerned with information

confidentiality – subjects reading from an object must have higher a security class than the object. – objects being written to by a subject must have higher security class than the subject.

  • The Biba model emphasizes information integrity

– subjects writing information to an object must have higher a security class than the object. – objects being read from by a subject must have higher security class than the subject.

Ross Anderson

slide-39
SLIDE 39

39

  • Does not deal with information flow through

covert channels

slide-40
SLIDE 40

40

slide-41
SLIDE 41

41

slide-42
SLIDE 42

42

slide-43
SLIDE 43

43

  • Requests by a subject to access an object are

controlled with respect to the access class of the subject and the object and granted only if some relationship, depending on the requested access, is satisfied

  • Two principles, must be satisfied to protect

information confidentiality

– No-read-up: A subject is allowed a read access to an object

  • nly if the access class of the subject dominates the access

class of the object – No-write-down: A subject is allowed a write access to an

  • bject only if the access class of the subject is dominated

by the access class of the object

slide-44
SLIDE 44

44

  • Satisfaction of these two principles prevents

information to flow from high level subjects/objects to subjects/objects at lower (or incomparable) levels, thereby ensuring the satisfaction of the protection requirements (i.e., no process will be able to make sensitive information available to users not cleared for it)

  • It is important to control both read and write
  • perations, since both can be improperly used to

leak information

slide-45
SLIDE 45

45

  • Consider the earlier example of the Trojan Horse
  • Possible

classifications reflecting the access restrictions to be enforced could be: Secret for Vicky and Market, and Unclassified for John and Stolen

  • In the respect of the no-read-up and no-write-down

principles, the Trojan Horse will never be able to complete successfully

– If Vicky connects to the system as a Secret (or Confidential) subject, and thus the application runs with a Secret (or Confidential) access class, the write operation will be blocked – If Vicky invokes the application as an Unclassified subject, the read operation will be blocked instead

slide-46
SLIDE 46

46

  • Given the no-write-down principle, users are allowed

to connect to the system at different access classes, so that they are able to access information at different levels (provided that they are cleared for it)

  • A lower class does not mean “less” privileges in

absolute terms, but only less reading privileges

  • Although users can connect to the system at any

level below their clearance, the strict application of the no-read-up and the no-write-down principles may result too rigid

slide-47
SLIDE 47

47

  • Real world situations often require exceptions to the

mandatory restrictions

– data may need to be downgraded – information released by a process may be less sensitive than the information the process has read

  • To respond to situations like these, multilevel

systems should then allow for exceptions, loosening

  • r waiving restrictions, in a controlled way, to

processes that are trusted and ensure that information is sanitized (meaning the sensitivity of the original information is lost)

slide-48
SLIDE 48

48

  • Note also that DAC and MAC policies are not

mutually exclusive, but can be applied jointly

  • In this case, an access to be granted needs both

– the existence of the necessary authorization for it and – to satisfy the mandatory policy

  • Intuitively, the discretionary policy operates within

the boundaries of the mandatory policy: it can only restrict the set of accesses that would be allowed by MAC alone

slide-49
SLIDE 49

Multilateral Security

49

slide-50
SLIDE 50

Multilateral Security

  • Sometimes the aim is to

stop data flowing down

  • Other times, you want

to stop lateral flows

  • Examples:

– Intelligence – Competing clients of an accounting firm – Medical records by practice or hospital