Security

1

• Security Integrity
• Information maintained in a DBMS is often used
  both in day-to-day operation of an enterprise,
  and in management support forecasting,
  budgeting, financial control.
• This information is a very valuable resource for
  an enterprise, and must be protected.
• Threats are of three basic types
• Loss of availability / Denial of service
• Loss of reliability / Corruption of data
• Loss of confidentiality / Snooping

2

• Security concerned with protection of database
  against unauthorised disclosure, alteration, or
  destruction granting access to confidential
  information for authorised users only. Some info
  can be so crucial that its loss could ruin an
  enterprise.
• Integrity concerned with preserving the
  consistency and the accuracy of data protecting
  against both malicious and accidental
  interference even by authorised users. (Recovery
  techniques and Concurrency Control may be seen as
  ways of defending database integrity)

3

• Examples of sensitive data
• Financial Banks Customer accounts
• Credit reference Credit ratings
• Medical Hospitals, clinics Patient data
• Military Army, Navy etc Secret weapons
• Force deployments
• Commercial Retail sales Mailing lists
• Distribution Selling strategies
• Industrial Manufacturing Processes
• New product plans

4

• How much should one invest in security and
  integrity?
• It can be difficult to quantify the value of
  information. Often it does have a clear economic
  value but in a hospital, data corruption in the
  DBMS might lead to patients receiving the wrong
  treatment, or none at all.
• Another important consideration is privacy of
  individuals
• many countries now have privacy laws these may
  require that information be used only for that
  purpose for which it was collected, and that it
  be accurate.

5

• Kinds of misuse of Computer Systems
• theft of money eg EFT
• theft of goods managed by computer
• access to proprietary information such as trade
  secrets
• access to sensitive information, for blackmail,
  for espionage, for terrorism
• harmful/illegal revelation of personal data
• theft of computer services
• theft of computer software
• long-term or short-term denial of service (by
  virus, worm)
• (Only the last 3 unique to computer systems)

6

• DBMS security, integrity
• DBMS give rise to different problems than general
  systems, problems which are therefore amenable to
  different solutions.
• DBMS have many different users
• DBMS store many kinds of information
• Data is shared, hence need to restrict users to
  those portions of database that are required for
  their legitimate activities, and need to control
  the changes that users can make.
• When data is changed, in a DBMS the old data is
  lost hence need for a recovery mechanism.
• Because data is shared, concurrency control is
  needed to maintain integrity.

7

• Some security issues are external to DBMS
• operating system hardware - vulnerabilities,
  security mechanisms
• physical controls - locked rooms terminals,
  guards at doors
• fireproof safes for backups
• policy questions
• how to decide who sees what?
• what about hiring and using and trusting computer
  staff?
• legal/social/ethical issues
• perhaps the public has a legal right to see
  certain data

8

• Some terminology exists (page 1 of 5)
• Information security protection of information
  against unauthorised disclosure, alteration,
  destruction.
• Database security protection of information
  maintained in a database.
• Protection refers to techniques that control
  the access of executing programs to stored
  information includes hardware and OS features.
  All access to computerised data must be by
  program.
• Printouts thrown in bins, forensic scans of
  disks, are beyond scope

9

• Terminology 2/5
• Auditing examination of information by persons
  other than those who produced it, often a
  considerable time after it was created or
  modified, focusing on what was done and by whom.
• Privacy all legal and ethical aspects of
  personal data systems (systems containing
  information about individuals). Individuals
  usually have a legal right to some control over
  information maintained about them.
• Authorisation the specification of rules about
  who has what type of access to what information.
  An authoriser writes access rules.

10

• Terminology 3/5
• Access control ensuring that information is
  accessed only in authorised ways.
• Information transfer to program is permitted
  subject to access rules.

11

• Terminology 4/5
• Intentional resolution when rules aim also to
  control actions on data once legally accessed.
• System limits the user program actions.
• Information flow control prevention of security
  leaks as information flows through the system.

12

• Terminology 5/5
• Integrity consistency, reasonableness,
  correctness of data
• Integrity subsystem the mechanisms that help
  ensure integrity of data
• System integrity ability of system to function
  according to specification even in the face of
  hacking.
• Semantic integrity concerned with the
  correctness, especially the internal consistency,
  of the data in the database in the presence of
  user updates. Data model may impose specific
  integrity constraints. Concurrency control
  recovery mechanisms are significant here.

13

• Relationship between security integrity

attempted
14

• Privacy requirements
• Decision making is increasingly based on
  impersonal recorded information rather than on
  personal knowledge.
• What is privacy - the right to be let alone?
• Information privacy has been defined as
• the claim of individuals, groups, or
  institutions to determine for themselves when,
  how, and to what extent information about them is
  communicated to others.

15

• The concept of administrative secrecy is
  related, and is usually covered by much more
  powerful legislation e.g. the British Official
  Secrets Act makes it an imprisonable crime for a
  government servant to reveal official
  information.
• Different legislatures take different approaches
  to privacy legislation.

16

• USA
• Fair Credit Reporting Act
• - affects private sector information systems
• - obliges credit bureaux to allow customers of
  credit institutions to review their own files
• It is a law tailored to one specific industry.
  Other specific laws cover other industries.

17

• USA
• Code of Fair Information Practices
• - for health, education welfare depts
• - no secret systems
• - individuals can find out what info is kept and
  how it is used
• - individuals may correct info
• - info collected for one purpose is not to be
  used for any other without consent
• - an organisation maintaining personal
  information must guarantee its reliability and
  must take precautions against its misuse
• Last stipulation is very important for DBMS.

18

• USA Privacy Protection Study Commission opted for
  laws tailored to specific private sector
  industries rather than using same provisions as
  for public sector (which is the approach taken in
  Europe). It recommended 3 basic objectives
• minimise intrusiveness
• individuals must be informed about any
  record-keeping taking place
• some info not collected at all
• limit methods of collection

19

• maximise fairness
• subject should be able to see records, correct
  errors, (refuse to) authorise disclosure
• fairness implies integrity must be maintained
• establish obligations about using and disclosing
  personal data
• Laws passed in 1978-79 embody some of its
  recommendations.

20

• Europe
• Swedish Data Act (1973) was the first national
  privacy law anywhere. It requires record-keeping
  systems to be licensed by, and inspected by, a
  board which may issue directives for the system.
• Germany, Denmark, Norway, France followed with
  similar laws. France's law additionally requires
  purging of obsolete information.

21

• European 1981 Convention for the Protection of
  Individuals with regard to the automatic
  processing of personal data, led in time to
• Britains Data Protection Act (1984)
• Ireland's Data Protection Act (1988)
• These two similar laws protect "personal data" -
  data relating to living individuals they apply
  only to computer-based records they exempt those
  using records solely for accounting, pay, or
  pension purposes.
• They establish
• - a data protection registrar (commissioner) of
  personal data users computer bureaux, who has
  powers to ensure that data is used according to
  the data protection principles.
• - appeals tribunal for data users
• - right of access for data subjects
• - right to compensation

22

• UK Ireland Obligations for data users
• must register
• describing personal data to be used and its
  purpose
• source of data
• persons to whom it will be disclosed
• places to which it will be transferred
• addresses for requests from data subjects
• - after registration, must not process data
  except as specified
• - must not transfer out of the country (UK,
  Ireland) except as specified
• - must allow subjects access to data about them
  (maybe with a fee)
• - may not allow anyone access to data about
  anyone else who has not consented to this. Can
  even refuse a person access to his own data if
  this involves revealing someone elses.

23

• Registrar (commissioner) may prosecute for
  breach, and may seize data (subject to various
  conditions)
• Appeal may be made to Data Protection Tribunal
  (Circuit Court).
• Various principles for data protection, not just
  for personal data. Eg
• data held only for clearly defined purpose
• data should be minimum necessary for job
• all data as accurate as possible
• data held only as long as necessary
• access restricted to authorised users

24

• Data Protection Acts lay down 8 principles for
  data users
• personal data information must be both obtained
  and processed fairly and lawfully
• p. data should be held only for the specified
  lawful purposes
• p. data shall not be used or disclosed for any
  purpose other than those specified
• p. data should be adequate, relevant, and not
  excessive for its purpose to the system
• p. data should be accurate and up-to-date where
  necessary
• p. data should be kept no longer than necessary
  for required purpose
• individual is entitled to
• a) without undue cost or delay,
• be informed if data is held,
• and be given access to it
• b) have it corrected or erased

25

• Eighth principle applies also to bureaux, not
  just data users, and was the most far-reaching
  from computer community viewpoint
• 8. all who run computer systems dealing with p.
  data, whatever the size of the system, are to
  adopt security measures against
• unauthorised access
• unauthorised alteration/destruction
• unauthorised disclosure
• accidental loss/destruction
• The essence of the law data must be true and
  must be fairly processed.

26

• Some privacy issues
• Electronic Funds Transfer (EFT)
• EFT systems automatically process deposits,
  withdrawals, and transfers of money eg Pass,
  Paypath, Banklink, Direct Debits, Debit/Credit
  cards.
• Expansion of EFT allows more details to be
  recorded and to be easy to retrieve could be
  used e.g. to trace an individuals movements or
  e.g. to classify for direct advertising purposes.
  (Like Tesco, Dunnes )
• Transborder Data Flow (TDF)
• Data can pass across international borders via
  networks rogue permissive economies?

27

• Universal Identifiers
• Social Security number Citizen Number?
• Great concern about the use of universal
  identifier to link personal records maintained
  in many different databases - making it easy for
  Big Brother also dehumanising effect - eg if
  computer grades exams, sends results, and sends
  success/failure letters to job applicants.
• US Privacy Commission recommended that steps be
  taken to prevent Universal Labels.

28

• Security Threats Defences
• Additional reference
• Database Security, Castano, Fugini, Martella
  Samarati
• Addison-Wesley, 1995
• Threats, malicious or accidental
• Malicious attack exploit system loopholes
  abuse privileged position use anothers
  password etc...
• Accident hardware/software failure natural
  disaster (fire, flood,...)

29

30

• Security Procedures Mechanisms - 1
• DBMS security - weakest link amongst human,
  software, and hardware measures. Wide range of
  protective measures must be adopted.
• external
• security clearance of personnel
• security policy formulation
• measures to protect passwords
• control over programming
• auditing
• data storage
• backup copies
• replication
• encryption

31

• Security Procedures Mechanisms - 2
• communication lines and physical environment
• prevent electronic eavesdropping
• secure areas for equipment files
• radiation shielding
• software
• user identification authentication
• access control
• recording audit trail
• hardware
• memory protection
• states of privilege

32

• Confinement problem while program legitimately
  conveys information to lawful user, it might also
  be conveying it to an unauthorised person, using
  legitimate or covert channels.
• e.g. using a file intended to pass info -
  legitimate channel
• e.g. using a file not intended to pass out info,
  or some coding scheme - covert channel.

33

• Verification methods might be used to show that a
  program meets security requirements but this may
  be too difficult.
• It would be nice to verify those parts of the
  security system that check accesses of untrusted
  programs beats Trojan Horse attack where flaw is
  deliberately left in security system.
• Security Kernel approach
• Some limited portion of the software contains all
  the basic security mechanisms only the kernel
  needs to be verified.

34

• Costs Benefits of security
• Software costs
• lower performance
• greater complexity
• loss of flexibility
• Human costs
• must administer system
• must maintain system
• Hardware costs
• may need special hardware, eg badge readers
• may need bigger better computers to offset
  performance hit
• Startup cost Operational cost
• Finance
• (privacy legislation has major cost implications
  for data users this was a cause of much
  opposition to the legislation.).

35

• Costs Benefits of security
• Protection benefit against security losses, e.g.
• trade secret loss,
• military loss,
• privacy loss.
• Reliability benefit
• security may lead to more discipline and so maybe
  more reliability.

36

• Security Evaluation Guidelines
• Completeness depends on sensitivity of data
• Confidence will it do the job? No proof.
• System flexibility different policies possible -
  the law may change
• Ease of administration
• Flexibility for users should not overburden
  users - user transparency
• Tamperproofness security system itself protected
• Low processing overhead
• Low operating costs hardware, software, salaries
• These factors have to be balanced for a
  particular enterprise in its particular
  environment.

37

• Overview of DBMS security
• Authentication follows identification and is a
  way to verify the identity of a user at log-on
  time. Fundamental to good security. Use of
  passwords is very common, also badges physical
  characteristics (retina scan voiceprint
  handprint etc)
• Authorisation for each transaction is checked by
  system.
• Access rules control access to system objects
  data, programs.
• DBMS checks authorisation, maintains integrity,
  synchronises concurrent transactions, looks after
  logging for security and recovery purposes.

38

39

• Policies for DBMS security
• Security policy guidelines concerning
  security of information.
• Implemented by security mechanisms (hardware,
  software, administration)
• Different policies for different enterprises -
  may have legal aspects.
• A given policy should not be built into a
  mechanism because as changes come about you may
  want to, or be obliged to, change policies.
• Some general-purpose mechanisms do allow a number
  of policies to be used (e.g. access rules)
• But special purpose mechanisms may be simpler to
  implement and may perform better because they can
  be tailored to a given system.
• Trade-off situation penny-wise pound-foolish.

40

• DBMS policy issues
• centralised vs. decentralised authorisation?
• will you have a single authoriser for the entire
  system, or different authorisers for different
  parts. (Not just an issue in distributed DB)
• ownership vs. administration functions
• is data owner (creator of data, if one exists)
  responsible for authorisation, or is there a
  separate administrator who defines controls its
  use?
• owner has full access to the data
• administrator merely controls access rights.
• (As in O.S., administrator can give himself full
  access - this is a problem. Who guards the
  guardians?)

41

• Access Control Specification policies
• need to know policy
• restrict information to those who must have it.
  Also called policy of least privilege because
  users and programs operate with the minimal set
  of privileges necessary.
• maximised sharing policy
• make the most of the data in a database, as eg in
  a library. May still have restrictions.
• Open systems - allow access to data unless
  explicitly forbidden,
• Closed systems - allow access to data only if
  explicitly authorised
• Closed systems are more safe (eg if an access
  rule is forgotten or destroyed), and are thus a
  basic requirement for a need-to-know policy.

42

• Name-dependent access control
• Demands ability to restrict access to finest
  granularity of DBMS, e.g. salary attribute of
  Person relation. An Access Rule names the
  attributes that can be accessed.
• Also called content-independent access control
  because the access rules do not use data values
  in making access decisions.
• Content dependent access control
• Extends policy of least privilege further than
  name-dependent access control. Rules refer to
  data values in DBMS, eg manager may see the
  salary field of records of employees managed by
  himself.

43

• Access types
• Degree of control over data is increased by
  having possibly different rules governing
  different types of access read, write, update,
  delete, insert, etc.
• In an office setting e.g.,
• Manager may have all rights over all fields of
  employee records
• Mail room has only read access, and only to
  name dept fields.
• Generally, each user has the minimum access
  rights required.
• Implementation (use by authoriser) is simplified
  if access rights are partially ordered e.g.
  update ---gt read

44

• Contrast with Functional Access Rights
• For a statistical database, e.g. census data,
  one requires the ability to do count average
  and sum functions, but one wants to prohibit
  queries that allow inferences about individuals.
• So-called tracker queries masquerade as
  statistical enquires but actually find
  information about an individual.
• eg select sum (salary)
• where firstname like A and
• lastname like C and
• school CSI
• (virtually?) impossible in practice to prevent
  construction of sets of queries designed to
  reveal information about an individual.
• So, add noise?
• Or, place upper lower bounds on number of items
  in an aggregate

45

• Context Dependent Control
• Access Rules refer to combinations of items that
  are impermissible
• May for example disallow queries that combine
  "name" and "salary", while permitting separate
  access to the two fields.
• But this is not really adequate to prevent
  extracting information about forbidden
  combinations of items, e.g. names salaries,
  because it might be possible to draw inferences
  from the results of separate queries e.g.
• q1 names and projects
• q2 projects and salaries
• Hence, goal of History Dependent Control
• To take account of the context of past and
  current requests.

46

• Policies to control information flow
• Previously mentioned policies control access to
  data, but not the use of data once accessed they
  assumed "Discretionary Access Control", where the
  authoriser grants access rights to users.
• In a "Compartmentalisation Policy" (also known as
  "non-discretionary access control"), data
  belonging to one user compartment cannot be
  accessed by users assigned to other compartments.
• This can be extended to Multi Level Control
  where, besides having compartments, information
  is classified according to sensitivity
• Unclassified Confidential Secret Top secret

47

• Users, and data, are assigned a security level.
• Security level is defined as a classification a
  set of categories (Army, Navy, Air Force)
• A User access is allowed iff
• user security level gt data security level.
• Level A gt Level B iff
• classification(A) gt classification(B) and
• categories(B) ? categories(A)
• ( ? meaning is subset of )

48

• Relation of policies supporting least privilege
• Enforcement of security policies embraces
• Detection of breaches and attempted breaches
  (auditing of log)
• Prevention of breaches

need to know
nondiscretionary access control
discretionary access control
statistical queries
security compartments
security levels
name dependent
context dependent
content dependent
multilevel control
history dependent
49

• Security Models
• Basic model using access matrix, from O.S. work
  originally by Lampson, Graham, Denning.
• Model has 3 components
• set of objects
• objects are entities known to system which must
  be protected eg memory, files, processes
• set of subjects
• subjects are entities (e.g. processes) requesting
  access to objects
• Subjects are objects too
• set of rules defining types of access a subject
  has for an object
• e.g. read, write, execute,confer privilege

50

• The set of all rules (conceptually) forms an
  Access Matrix A, where
• columns represent objects (O1..On),
• rows represent subjects (S1..Sm),
• an entry ASi,Oj contains a list of access types
  t1,t2,... specifying access privileges of subject
  Si to object Oj.
• The list of objects that a subject may access,
  together with the access types, is termed a
  Capability List.
• The list of subjects that may access an object,
  together with the access types, is termed an
  Access Control List.

51

• This model treats the security of system objects
  in a uniform way and so one could consider DBMS
  security as a mere extension of OS security,
  allowing database objects in the access matrix
  then OS would handle all security. But there are
  OS/DBMS differences
• Many more DBMS objects
• DBMS security may involve levels of granularity -
  record, field
• OS protects real resources, DBMS has complex
  logical resources
• OS would become too complex better to do DBMS
  security separately, and develop a separate model
  for DBMS.
• Use similar ideas as above but
• objects are relations records fields, whose
  names are known to DBMS
• subjects are end users, or groups of them, or
  their programs
• access types are operations such as read, write,
  update, delete
• access matrix is modified only by the authoriser

52

• The model does not imply any implementation
• Actually using a matrix will very likely be
  storage inefficient.
• Using capability lists alone makes generation of
  ACLs expensive
• And vice versa

53

• Access matrix can model name dependent policy to
  any level of granularity. But it needs an
  extension for content-dependent policy
• Access rules must contain also a predicate, an
  expression defining a condition on set
  membership.
• Let OP be the subset of the objects O for which
  the predicate P is true notation OP O P
• Now represent an access rule by a tuple (s, O,
  t, Pprot)
• specifying that subject s has access t to those
  members of O satisfying Pprot
• eg access to employees with salary lt 20000
• ( s O t Pprot )
• ( clerk employee read sallt20000 )
• The set OPprot is the effective object of the
  access.

54

• Predicate could also be used for constraints
• integrity constraints (see later)
• access time control (eg Mon-Fri 9-5)
• ie uses data obtained from system
• Some context-dependent access control is
  possible, if the predicate examines the whole
  query for fields that cannot occur together.
• The data that is retrieved (from DB or otherwise)
  to evaluate the predicate is termed the
  protection data
• Access control involves
• rule specification
• validation process (all accesses authorised)
• Validation rules govern interpretation of access
  rules.

55

• Access requests of the form
• (s, O, t, Puser )
• (s requests access t to set OPuser )
• are passed to validation process
• (assume s is already authenticated).
• If there is a rule (s, O, t, Pprot )
• then protection data to evaluate the predicate
  Pprot is retrieved.
• If no access rule exists, or the predicate Pprot
  evaluates to false, then request is denied.

56

• (nb. must also have read access to fields
  specified in Puser, otherwise inferences may be
  drawn from either retrieval or non-retrieval of
  data but can there be problematic recursion in
  validating this access?)
• Partial match may arise, where access is
  permitted to some but not all fields then
  validation might
• allow only the authorised fields go through -
  vertical subset
• or do query modification, allowing through only
  those records in subset satisfying the predicate
  p - horizontal subset.

57

• Extensions to basic model
• control over set of access rules.
• eg only allow authoriser who wrote a rule to
  change it.
• Rule specifies authoriser a (a, s, O, t, P)
• the right to delegate rights is a kind of access
  to the rules (O, t, P).
• Subjects may be allowed to do this
• Principle of Attenuation Of Privileges is
  commonplace
• Add "copy flag" f to the rule, specifying whether
  subject is allowed to delegate access right (a,
  s, O, t, f, P)
• extend rule further with auxiliary procedures to
  be used during validation (eg to specify what to
  do when access is denied - perhaps log on
  console). Their use may be contingent on
  validation decision must specify conditions and
  procedures
• (C1,AP1, ... Cn,APn)
• Fully extended rule (a, s, O, t, f, P,
  (c1,ap1, ... cn,apn))
• But basic rule is sufficient for most purposes
  (s, O, t, P)

58

• Multilevel models
• Non-discretionary access control
• - each subject has clearance level
• - each object has classification level
• A subject is a process executing on behalf of a
  user, and having a clearance level no greater
  than that of the user.
• objects are storage areas, variables, files,
  I/O devices.

59

• Security level comprises classification level
• set of categories
• One level L1 dominates another L2 iff
• L1s classification-level L2s
• L1s category set contains L2s
• Access primitives
• observe object (extract info from it)
• alter object delete object (execute object)
• Access types (for db)
• none
• observe only (READ)
• alter only (APPEND)
• observe alter (WRITE)

60

• States of a secure system are described by
• - current access set - (s, o, t)
• - access matrix (optional to provide additional
  discretionary control)
• - security level of each object
• - max. and current security levels of each
  subject
• System state change is caused by requests
• - obtain/drop access to object
• - change current security level
• raise/lower classification level
• extend/reduce category set
• - create/destroy objects
• System uses rules to decide its response to each
  request, taking account of current state. Rules
  specify how each request is to be handled.

61

• Prove system is secure by proving that each rule
  is security-preserving.
• Secure state possesses
• Simple security property
• for every access (s, o, observe), level(s)
  dominates level(o)
• The snag is that once a subject has got
  information from a high-level object (e.g. top
  secret), he might put it into another, low-level,
  object (eg unclassified)
• Confinement property (-property) combats this
• For every access (s, o, t)
• if t read, current level dominates level(o)
• if t append, level(o) dominates current
  level
• if t write, level(o) current level
• Extra rules govern creating and destroying
  objects, changing user level.

62

• Information flow model (Lattice model Denning)
• Generalises the information-flow aspects of
  multilevel model.
• Sensitivity category make up security class
• For a specific system, the information flow model
  comprises
• set of objects
• set of subjects
• set of security classes
• A class-combining operator " ? "
• The class-combining operator specifies the class
  of the object formed by combining any two objects
  of any two classes.
• e.g. concatenating objects of classes A, B yields
  an object of class A?B
• A flow relation "? "
• The Flow Relation (A ? B) lists all pairs of
  classes A, B where information in
  subjects/objects of class A may flow into
  subjects/objects of class B.

63

• Flow model is secure if flow relation cannot be
  violated.
• A lattice is formed by classes, ?, ?
• A lattice is a partially ordered set, plus least
  upper bound, greatest lower bound operators
• Example lattice has 3 basic types of data -
  medical data, financial data, criminal data.
• Information always flows into classes at least as
  inclusive.
• ? for this lattice yields a union of 2 classes.

64

• Moving information from m, f into m ought to
  be regarded as a violation, assuming m is
  designated for medical information only.
• A flow policy is a tuple lt S, ? gt
• S set of security classes
• ? flow relation (permissible flows between pairs
  of classes)
• Each object x is bound to a security class, X.
• (It is assumed that the bindings are static and
  are declared in programs.)
• To allow us to regard the tuple lt S,? gt as a
  lattice, we also assume
• - finite number of classes
• - flow relation is reflexive and transitive

65

• Information flows from an object x to an object y
  (written x ? y) either when information stored in
  x is transferred to y, or when information in x
  is used to derive other information that is
  transferred to y.
• A program statement specifies a flow x ? y if
  execution of that statement could result in such
  a flow.
• Flows may be explicit , or implicit e.g. if a0
  then bc
• there are flows c?b and also a?b
• A program P is secure iff all flows, explicit or
  implicit, are secure. i.e. no execution of P
  results in a flow x ? y unless X?Y

66

• A necessary and sufficient, but undecidable,
  condition for the security of a program P is
• x ? y for some execution of P only if X ? Y
• Deciding this reduces to halting problem one
  must enumerate all execution paths. A decidable
  approximation is
• x ? y is specified by a statement of P only if X
  ? Y
• This lacks precision.
• Consider the statement if xlt0 then if xgt0 then
  yz
• This statement specifies x?y but no execution
  could cause the flow to occur. The code is
  secure, even in absence of X?Y, but would fail
  the certification test.

67

• A Certification process can be built into a
  compilers program-analysis phase, provided that
  security classes are static and are declared.
  Certification semantics is used in a similar
  fashion to type checking.
• Confinement problem Procedure is confined if
  system guarantees that customer information
  cannot be retained and cannot be encoded for
  transmission.
• In DBMS, a user (one kind of subject) has a
  clearance u. If users query is to retrieve a
  result composed from objects of classes x1xn,
  then it must be verified that (x1? ? xn) ? u.

68

• Processes have 3 information transmission
  channels (Lampson)
• - legitimate channels (formal outputs)
• - storage channels
• these can be verified
• - covert channels (eg runtime, paging)
• provide only very slow transmission, but cannot
  be easily handled
• Model comparison
• Access Matrix approach is flexible, permits a
  wide range of policies
• With Information Flow approach, introduction of
  new objects may require new lattice structure,
  with runtime overhead costs .

69