Policy-based Access Control for Weakly Consistent Replication Based - PowerPoint PPT Presentation

Policy-based Access Control for Weakly Consistent Replication Based on paper written by Ted Webber, Thomas L. Rodeheffer and Douglas B. Terry

Outline • What’s the problem? • Definitions • System design – Operation on data – Updating policies – Mantaining weak consistency • Summary • Questions

What’s the problem? • Suppose we have small network • We want to share resources between devices • All devices should have different access rights

What’s the problem? • We want to grant limited access to resource for every replica according to the policy • Replicas are not uniformly trusted • Data can change • Data can be divided into categories • Policy can change • State must be (eventually) consistent

That’s not so easy! • Each replica has its policy P and dataset U P’ U’ T 0 T 1 P, U P, U P’, U P, U’ A B A B T 2 T 3 U’ P’ P’, U P, U’ P’, U P’, U’ A B A B

Definitions • Collection is a dataset to replicate – e.g. FS subtree, SQL database, personal contacts... • Collections consist of items , which are atomic • Collections appear in whole or in part on replicas

Assumptions • The network is consistent – All updates will reach eventually all authorized replicas • All updates take place in either of two ways – Through direct invocation – By helper application, like FS watcher • Replicas synchronize periodically • Only weak consistency is guaranteed

Observations • Updates can arrive out of order • There can occur replication conflict – concurrent update of the same item • Local view of policy can vary between replicas

System design • Items access and update by particular replicas • Policy access and update • Providing eventual consistency

Operations on items Let’s specify three primitive operations: • Write – When a replica receives an item during synchronization • Read – When a replica is considering wether to send an item during synchronization • Sync – When a replica receives protocol-specific metadata required for performance or correctness

Operation on items And two additional, administrative rights: • Control – Means that the replica can grant rights to read and write to other replicas • Own – Means that the replica can grant any rights to other replicas, including own and control

Example

Example Replica Read Write Sync Control Own HomePC All All All All All Laptop All All All Contacts Contacts MediaPlayer Photos - - - - Cloud All - All - - Work Contacts Contacts - - - Mobile Contacts Contacts - Contacts - SpouseMobile Contacts - - - -

Replicas • Every replica has its own set of rights to different types of items • Every replica has unique public key • Update is signed with author’s public key to determine the authorship • We have three special replicas – Local Authority (LA) – Annonymous – Collection Manager (CM)

Labels • Due to performance issues, the policy is not defined for every single item • Items are divided into classes represented by labels • Labels are immutuable • Can be structured in hierarchcal namespace • In the example we have two labels: contacts and photos

Items • Items are bound to certain label • It is impossible to change item’s label • Item’s identifier is of the form uniqueId$hash , where hash is cryptographic hash of the corresponding label • By signing an item, a replica declares that it has write permissions on the assosiated label. What if replica is bogus?

Policies • Policy is set of claims • Claims are used to prove target assertions • In the described protocol authors use SecPAL evaluator which operates on XML objects

Claims • Claim is a statement made by replica about a fact „A says B can write contacts” OR „A says B can write contacts if B can write photos” • Facts come in four forms: – „A says B can ...” – „A says B can say ...” – „A says B revokes ...” – „A says B can revoke ...”

Special Replicas Let’s remind that we introduced three special replicas: • Local Authority (LA) – Any direct claim made by LA is believed – All such claims are hard-coded as policy axioms • Anonymous – Means „everybody” – All claims refering to Anonymous refers to anybody • Collection Manager (CM) – Has all rights to all resources – Holds only replicated policy

Policy axioms • Policy axioms are hard-coded as LA claims: „LA says P can say Q can { read, write } L if P can control L ” „LA says P can { read, write, sync, control } L if P can own L ” „LA says P can say Q can { own, read, write, sync, control } L if P can own L” „ LA says CM can own all ”

Target assertion • Target assertion is a final claim that we want to prove • Supose we want to check if Mobile can write contacts The target assertion takes form of: „LA says Mobile can write contacts ” Proof proceeds with using claims made by authorized replicas

Delegating specific rights • In order to make a target assertion provable we have to add more claims • Continuing the example from slides 12-13 we create new claim „CM says HomePC can own all ” • Policy claims are signed by their issuers

Delegating specific rights • HomePC creates replicas for Cloud and MediaPlayer and creates following claims: „HomePC says Laptop can { read, write, sync } all ” „HomePC says Laptop can own contacts ” „HomePC says Cloud can { read, sync } all ” „HomePC says MediaPlayer can read photos ” • Afterwards Laptop creates replicas for Work and Mobile , and so on...

Policy representation • Policy claims are encoded as XML files and stored in collection items called policy items • These are regular items, so we bind them to label policy and we add two more claims „CM says Anonymous can read policy ” „ HomePC says Laptop can write policy.homepc.laptop”

Example of proof LA says SpouseMobile can read "contacts" | | | +-LA says P can say Q | | | | | can own R if P can own R +-LA says Laptop can say SpouseMobile | | | | | | can read "contacts" | | | +-LA says CM can own "contacts" | | | | | | | +-LA says P can say Q can read R if | | | +-LA says CM can own "" | | P can own R | | | | | | | +-CM says HomePC can own "contacts" | +-LA says Laptop can own "contacts" | | | | | | | +-CM says HomePC can own "" | +-LA says HomePC can say Laptop | | | | | can own "contacts" | +-HomePC says Laptop can own "contacts" | | | | | | | +-LA says P can say Q can own R if | +-HomePC says Laptop can own "contacts" | | | P can own R | | | | +-Laptop says SpouseMobile can read "contacts" | | +-LA says HomePC can own "contacts" | | | | +-Laptop says Mobile can say SpouseMobile | | +-LA says CM can say HomePC | | can read "contacts" | | | | can own "contacts" | | | +-Laptop says Mobile can say | P can read "contacts" | +-Mobile says SpouseMobile can read "contacts"

Revocation • Revocation claims are more less the same as normal policy update „ Laptop says Laptop revokes write contacts from Mobile ” • May result in invalidation of previously valid items! • It is impossible to revoke revocation or revocation right

Revocation conflict • There are two ways to deal with revocation conflict – Invalidate all affected items – Honor historical claims and disallow only new dependencies on revoked claims • In the solution proposed by authors the second option is implemented (with one exception)

Summary of design • Policy is encoded in a logical language • Authority flows from a single root (CM) • Access control checks are performed within the operations that implement data replication • Encoded policy is replicated as data

Mantaining consistency • There are separate items for any claims uttered by a given replica – Allows simultaneous policy updates • Read access controls do not apply to policy items – Replica cannot prevent policy from propagating

Difficult example Let’s remind example from slide 5, how the system sould behave? P’ U’ T 0 T 1 P, U P, U P’, U P, U’ A B A B T 2 T 3 U’ P’ P’, U P, U’ P’, U P’, U’ A B A B

Difficult example - answer • If U’ is not authorized at authoring replica, then the update will not be admitted • If U’ is not authorized at receiving replica, then transmission of U’ is retried periodically until P’ arrives a the destination • If U’ was inappropriately authorized before receiving P’, the replica must reevaluate all previously received items

Design - summary • Single root of authority • Identity determined with public key • Updating after checking the policy • Policy as normal items • Limitations on revoking claims • Binding of labels and data

Questions

References • T. Wobber, T. L. Rodeheffer, D. B. Terry. Policy-based Access Control for Weakly Consistent Replication in EuroSys Conference, Paris, France, pages 293-306, 2010