DAC and Trojan Horse Brown: read, write Employee Mandatory Access - PDF document

DAC and Trojan Horse Brown: read, write Employee Mandatory Access Control Brown B Read Employee R d E l Black, Brown: read, write REJECTED! Black’s Employee Black is not allowed To access Employee Black 1 2 Mandatory Access Control (MAC) DAC and Trojan Horse • Security level of object (security label): Brown: read, write Sensitivity of object Employee Word • Security level of subject (security class): user’s Processor clearance Reads – E g Top Secret > Secret > Confidential > Unclassified – E.g. Top Secret > Secret > Confidential > Unclassified Uses shared program Uses shared program Employee • MAC specifies the access that subjects have to Brown Black, Brown: read, write objects based on the subjects and objects Black’s Employee Copies TH classification Employee Inserts Trojan Horse To Black’s • This type of security has also been referred to as Into shared program Employee multilevel security Black Black has access to Employee now! 3 4 MAC – Controlling Information Mandatory Access Control (MAC) Flow • Controlling information flow (Bell-LaPadulla properties BLP): – No READ UP: Subject clearance  object security – No WRITE DOWN (*-property): Subject clearance  object security – Prevent information in high level objects from flowing – Prevent information in high level objects from flowing to low level subjects – Tranquility property: The classification of a resource cannot be changed while the resource is in use by any user of the system • Necessary but not sufficient conditions • May still have problems – covert channel – Indirect means by which info at higher levels passed to lower levels 5 6 1

Why Apply MAC to DB? MAC – Problems? • Data can be viewed as sensitive for many different • Write-up allows destruction of more secure info reasons. Examples: – personal and private matters or communications, professional – Limit to same level; disable write-up trade secrets, • Write-up means cannot send info to lower-level – company plans for marketing or finance, subjects – military information, or government plans y , g p – Subject can sign in at lower level • Such data is often mixed with other, less sensitive – Prevent malicious programs from leaking secrets information that is legitimately needed by diverse users – Users are trusted, not programs • Restricting access to entire tables or segregating sensitive data into separate databases can create a • Hierarchy of security levels is too restrictive working environment that is costly in hardware, software, – Lattice of security labels user time, and administration. 7 8 Multilevel Relational (MLR) Model Traditional Relational Model • The multilevel relational (MLR for short) Standard relational model – each relation is model results from the application of the characterized by two components BLP model to relational databases - A state-invariant relation scheme - R(A1, … ., An) where Ai is an attribute over - R(A1 An) where Ai is an attribute over • Several issues • Several issues some domain Di – Granularity: to which element do we apply the - A state-dependent relation over R classification? composed of distinct tuples of the form – Integrity constraints (a1, … , an), where each ai is a value in domain Di 9 10 Example Relational Model – keys and FD • Consider relation Hourly_Emps: • Functional dependencies – Hourly_Emps ( ssn, name, lot, rating, hrly_wages , hrs_worked ) – Let R be a relation and let X and Y be attribute sets, both subsets of the attribute set of R we say that X functionally determines Y if and S N L R W H FDs S  SNLRWH • only if not two tuples may exist in the same relation 123-22-3666 123 22 3666 Attishoo Attishoo 48 8 48 8 10 40 10 40 over R with the same value for X but different values over R with the same value for X but different values • ssn is the key ssn is the key for Y FDs give more detail than 231-31-5368 Smiley 22 8 10 40 • • Primary Keys (entity integrity property) the mere assertion of a key 131-24-3650 Smethurst 35 5 7 30 – the primary key uniquely identifies each tuple in the • rating determines hrly_wages relation 434-26-3751 Guldu 35 5 7 30 • R  W – A primary key cannot contain attributes with null 612-67-4134 Madayan 35 8 10 40 values – A relation cannot contain two tuples with the same value for the primary key 11 12 2

Multilevel (ML) relations MLR Model A ML relation is characterized by two components - A state-invariant relation scheme • Given a relation, an access class can be R(A1,C1, … ., An,Cn, TC) where: associated with: - Ai is an attribute over some domain Di - Ci is a classification attribute for Ai; its domain is the set of access – The entire relation classes that can be associated with values of Ai - TC is the classification attribute of the tuple – Each tuple in the relation p - A set of state-dependent relation instances Rc over R for • This is the common choice in commercial systems each access class in the access class lattice. Each – Each attribute value of each tuple in the instance Rc is composed of distinct tuples of the form relation (a1,c1, … , an,cn, tc), where: - ai is a value in domain Di • In the remainder we consider this case - ci is the access class for ai – Toward a Multilevel Secure Relational Data Model. Proc 1991 - tc is the access class of the tuple determined as the least upper ACM Int'l. Conf. on Management of Data (SIGMOD), 50-59. bound of all ci in the tuple - Classification attributes cannot assume null values 13 14 ML relations - example ML relations - instances Vessel (AK) Objective Destination TC • A given relation may thus have instances at different access classes Micra U Shipping U Moon U U • The relation instance at class c contains all data that are Vision U Spying U Saturn U U visible to subjects at level c – It contains all data whose access classes are dominated by c Avenger C Spying C A C S i C M Mars C C C C – All elements with access classes higher than c, or incomparable, are masked by null values Logos S Shipping S Venus S S – Sometimes, to avoid signaling channels, fictitious values (called cover story values ) can be used 15 16 ML relations - example MLS Model • Entity integrity rule Vessel (AK) Objective Destination TC – All attributes that are members of the apparent key must not be null (i.e., A i  AK  t[A i ]  NULL) Micra U Shipping U Moon U U – All attributes of AK must have the same security classification within each individual tuple (i.e., A i , A j  AK  t[C i ] = t[C j ]) Vision U Spying U Saturn U U – For each tuple, the access class associated with the non-key attributes must dominate the access class of the primary key (i.e., A i  AK  t[C i ]  t[C AK ]) A i  AK  t[C i ]  t[C AK ]) (i e Avenger C Spying C A C S i C Mars C C M C C • Null integrity Logos S Shipping S Venus S S – Nulls are classified at the level of the key – One tuple does not subsume another (null values subsumed by non-null values) • Inter-Instance Integrity • Level U users see first 2 tuples – User can only see portion of relation for which is cleared • Level C users see first 3 tuples – Data not cleared is set to null • Level S users see all tuples – Eliminate subsumed tuples 17 18 3