XML, distributed data, replicated data, and Security
Database (relational) concepts Database consistency Key constraints (referential integrity) Integrity constraints Data dependencies Normalization Multi-user environment Concurrency control Locking protocols Deadlock prevention/detection
Distributed Databases Database fragmentation Vertical Horizontal Commit protocols Database replication Mutual consistency Pessimistic replica control Optimistic replica control
Database Design Goal: Anomalies: Represent domain information Avoid anomalies Avoid redundancy Anomalies: Update: not all occurrences of a fact are changed Deletion: valid fact is lost when tuple is deleted
Functional Dependencies FD: X A for relation R X functional determines A, i.e., if any two tuples in R agree on attributes X, they must also agree on attribute A. X: set of attributes A: single attribute If t1 and t2 are two tuples of r over R and t1[X]= t2[X] then t1[A]= t2[A] What is the relation between functional dependencies and primary keys?
Example - FD Functional Dependencies: Name,Breed Age Weight Date Kennel Pepper G.S. 1 70 01/01/02 White Oak Buddy Mix 4 50 03/04/01 Little Creek 04/17/02 Panka Vizsla 12 40 02/14/02 Functional Dependencies: Name,Breed Age Name,Breed Weight
XML example Reference paper Figure 1 Figure 2 XML Keys XML FDs
Normalization Functional Dependencies: Name,Breed Age Weight Date Kennel Pepper G.S. 1 70 01/01/02 White Oak Buddy Mix 4 50 03/04/01 Little Creek 04/17/02 Panka Vizsla 12 40 02/14/02 Functional Dependencies: Name,Breed Age Name,Breed Weight
Normalization Relation: primary keys FDs that violate BCNF Decompose relation
Security Objectives Confidentiality Integrity Availability Authenticity Non-repudiation Access Control Models
DB Access Control Protection objects: system resources for which protection is desirable Memory, file, directory, hardware resource, software resources, etc. Subjects: active entities requesting accesses to resources User, owner, program, etc. Access mode: type of access Read, write, execute
Relational
Secure XML Views - Example medicalFiles <medicalFiles> UC <countyRec> S <patient> S <name>John Smith </name> UC <phone>111-2222</phone> S </patient> <physician>Jim Dale </physician> UC </countyRec> <milBaseRec> TS <name>Harry Green</name> UC <phone>333-4444</phone> S <physician>Joe White </physician> UC <milTag>MT78</milTag> TS </milBaseRec> </medicalFiles> countyRec milBaseRec physician Jim Dale physician Joe White milTag MT78 patient patient name John Smith phone 111-2222 name Harry Green phone 333-4444 View over UC data
Delete
XML Delete Operations Delete entire sub-tree under a deleted node Most widely used approach Problem: blind write Delete only the viewable nodes Problem: fragmentation of XML tree Reject the delete Problem: covert channel
Different Solution – Deleted Label Basic Idea A unique domain “Del” for deleted nodes Change security classification of deleted node (o, {do Del}) Perform after delete operation Change security clearance of users, where s = (s, {ds}) > (o, {do}) to ( (s, {ds}) , (o, {do Del}) ) Can be preprocessed Use BLP axioms
Example - Top Secret View Report Title Data Date Temperature Images Concrete Location Defense Sector (S,{Del}) TS P Subject clearances: (TS, {}) { (TS, {}) , (S, {Del}), (P, {Del}) } (S, {}) { (S, {}), (P, {Del}) } (P, {}) { (P, {}) }
Attribute Association
Node Association - Example MedicalDb Patient * Patient Phone Name Patient Birthdate Race Date Diagnosis Comments Phone Birthdate Name SSN Race Allergies Allergen * Date Diagnosis Physician Prescription * Comments DTD of Patient Health Record
Layered Access Control Object - Association level classification + - Node level classification
Updates Primary key: Person-name What happens if the public user wants to insert a tuple <Dell, AT&T, $45,495>
Do we need anything else? Security Objectives Confidentiality Integrity Availability Authenticity Non-repudiation Do we need anything else?