Bài giảng Bảo mật CSDL - Chap 3: Discretionary Access Control Models

Access ControlDiscretionary Access ControlChapter 3AgendaAccess Control Discretionary Access ControlAccess Control“Access control” is where security engineering meets computer science.Its function is to control which (active) subject have access to a which (passive) object with some specific access operation.subjectAccess requestReferencemonitorobjectAccess ControlDetermine whether a principal can perform a requested operation on a target objectPrincipal: user, process, etc.Operation: read, write, etc.Object: file, tuple, etc.Lampson defined the familiar access matrix and its two interpretations ACLs and capabilities [Lampson70]Why are we still talking about access control?An access control policy is a specification for an access decision functionThe policy aims to achievePermit the principal’s intended function (availability)Ensure security properties are met (integrity, confidentiality)Limit to “Least Privilege,” Protect system integrity, Prevent unauthorized leakage, etc.Also known as ‘constraints’Enable administration of a changeable system (simplicity)Example: Access ControlProf Alice manages access to course objects‣ Assign access to individual (principal: Bob)‣ Assign access to aggregate (course-students)‣ Associate access to relation (students(course))‣ Assign students to project groups (student(course, project, group))Prof Alice wants certain guarantees‣ Students cannot modify objects written by Prof Alice‣ Students cannot read/modify objects of other groupsProf Alice must be able to maintain access policy‣ Ensure that individual rights do not violate guarantees‣ However, exceptions are possible – students may distribute their results from previous assignments for an examAccess Control is Hard BecauseAccess control requirements are domain-specificGeneric approaches over-generalizeAccess control requirements can changeAnyone could be an administratorThe Safety Problem [HRU76]Can only know what is leaked right nowAccess is fail-safe, but Constraints are notAnd constraints must restrict all future statesSafety ProblemDetermine if an unauthorized permission is leaked givenAn initial set of permissions andAn access control system, mainly administrative operationsFor a traditional approach, the safety problem is undecidableAccess matrix model with multi-operational commandsMain culprit is create – create object/subject with own rightsProve reduction of a Turing machine to the multi-operational access matrix systemSafety ProblemResult led toSafe, but limited models: take-grant, schematic protection model, typed access matrix modelFurther support for models in which the constraints are implicit in the model e.g., lattice modelsCheck safety on each policy change – constraint approach of RBACCompare to Other CS ProblemsProcessor designHard, but can get some smart people together to construct one, fixed, testable designNetwork protocol designTCP: A small number of control parameters necessary to manage all reasonable options, within a layered architectureConstraints, such as DDoS, are ad hocSoftware designSpecific goals in mind to achieve function, constraints are ad hocAccess Control ModelsDiscretionary Access MatrixUNIX, ACL, various capability systemsMandatory (Usually) Access MatrixTE, RBAC, groups and attributes, parameterizedPlus TransitionsDTE, SELinux, JavaLattice Access Control ModelsBell-LaPadula, Biba, DenningPredicate ModelsASL, OASIS, domain-specific models, many othersSafety ModelsTake-grant, Schematic Protection Model, Typed Access MatrixAdministrationDiscretionary Access ControlUsers (typically object owner) can decide permission assignmentsMandatory Access ControlSystem administrator decides on permission assignmentsFlexible Administrative ManagementAccess control models can be used to express administrative privilegesType Enforcement [BoebertKain84]Group and AttributesAccess ControlDiscretionary Access ControlAccess Matrix ModelImplementation of the Access MatrixVulnerabilities of the Discretionary PoliciesAdditional features of DACDiscretionary Access ControlDiscretionary Access Control is an individual user can set an access control mechanism to allow or deny access to an object.Relies on the object owner to control access.DAC is widely implemented in most operating systems, and we are quite familiar with it.Strength of DAC: Flexibility: a key reason why it is widely known and implemented in mainstream operating systems.Discretionary Access Control Access to data objects (files, directories, etc.) is permitted based on the identity of users. Explicit access rules that establish who can, or cannot, execute which actions on which resources. Discretionary: users can be given the ability of passing on their privileges to other users, where granting and revocation of privileges is regulated by an administrative policy. Discretionary Access ControlDAC is flexible in terms of policy specificationThis is the form of access control widely implemented in standard multi-user platforms Unix, NT, Novell, etc.Limitation of DACGlobal policy: DAC let users to decide the access control policies on their data, regardless of whether those policies are consistent with the global policies. Therefore, if there is a global policy, DAC has trouble to ensure consistency.Information flow: information can be copied from one object to another, so access to a copy is possible even if the owner of the original does not provide access to the riginal copy. This has been a major concern for military.Malicious software: DAC policies can be easily changed by owner, so a malicious program (e.g.,a downloaded untrustworthy program) running by the owner can change DAC policies on behalf of the owner.Flawed software: Similarly to the previous item, flawed software can be “instructed” by attackers to change its DAC policies.Access control matrixDescribes protection state preciselyMatrix describing rights of subjectsState transitions change elements of matrixState of protection systemDescribes current settings, values of system relevant to protectionDiscretionary Access ControlAccess ControlDiscretionary Access ControlAccess Control Matrix ModelImplementation of the Access MatrixVulnerabilities of the Discretionary PoliciesAdditional features of DACAccess Control Matrix ModelAccess control matrix Firstly identify the objects, subjects and actions. Describes the protection state of a system.State of the system is defined by a triple (S, O, A)S is the set of subject,O is the set of objects,A is the access matrixElements indicate the access rights that subjects have on objectsEntry A[s, o] of access control matrix is the privilege of s on oDescriptionobjects (entities)subjectss1s2sno1 om s1 snSubjects S = { s1,,sn }Objects O = { o1,,om }Rights R = { r1,,rk }Entries A[si, oj]  RA[si, oj] = { rx, , ry } means subject si has rights rx, , ry over object ojBoolean Expression EvaluationACM controls access to database fieldsSubjects have attributesAction/Operation/Verb define type of accessRules associated with objects, action pairSubject attempts to access objectRule for object, action evaluated, grants or denies accessExampleSubject AnnieAttributes role (artist), groups (creative)Verb paintDefault 0 (deny unless explicitly granted)Object pictureRule: Annie paint picture if: ‘artist’ in subject.role and ‘creative’ in subject.groups and time.hour ≥ 0 and time.hour 40 & position = teacher) Should not be answered as Matt’s salary can be deducedCan be represented as an ACMNamePositionAgeSalaryCeliaTeacher4540KLeonardTeacher5050KMattTeacher3350KNamePositionAgeSalaryCeliaTeacher4540KLeonardTeacher5050KSolution: Query Set Overlap Control (Dobkin, Jones & Lipton ’79)Query valid if intersection of query coverage and each previous query < rCan represent as access control matrixSubjects: entities issuing queriesObjects: Powerset of recordsOs(i) : objects referenced by s in queries 1..iM[s,o] = read iffQuery 1: O1 = {Celia, Leonard, Matt} so the query can be answered. HenceM[asker, Celia] = {read}M[asker, Leonard] = {read}M[asker, Matt] = {read}Query 2: O2 = {Celia, Leonard} but | O2 Ç O1 | = 2; so the query cannot be answeredM[asker, Celia] =  M[asker, Leonard] =  Solution: Query Set Overlap Control (Dobkin, Jones & Lipton ’79)Access ControlDiscretionary Access ControlAccess Matrix ModelImplementation of the Access Control MatrixVulnerabilities of the Discretionary PoliciesAdditional features of DACACM ImplementationACM is an abstract modelRights may vary depending on the object involvedACM is implemented primarily in three waysAuthorization TableCapabilities (rows)Access control lists (columns)Authorization Table Three columns: subjects, actions, objects Generally used in DBMS systemsAccess Control List (ACL)Matrix is stored by column. Each object is associated with a listIndicate for each subject the actions that the subject can exercise on the objectCapability ListMatrix is stored by rowEach user is associated with a capability listIndicating for each object the access that the user is allow to exercise on the objectACLs vs Capability ListImmediate to check the authorization holding on an object with ACLs. (subject?)Immediate to determine the privileges of a subject with Capability lists. (object?)Distributed system, authenticate once, access various servers choose which one?Limited number of groups of users, small bit vectors, authorization specified by owner.Which one?Basic Operations in Access ControlGrant permissionsInserting values in the matrix’s entriesRevoke permissionsRemove values from the matrix’s entriesCheck permissionsVerifying whether the entry related to a subject s and an object o contains a given access modeAccess ControlDiscretionary Access ControlAccess Matrix ModelState of Protection SystemImplementation of the Access MatrixVulnerabilities of the Discretionary PoliciesAdditional features of DACVulnerabilities of the Discretionary PoliciesNo separation of users from subjectsNo control on the flow the informationMalicious code, i.e., Trojan horseExampleVicky, a top-level managerA file Market on the new products releaseJohn, subordinate of VickyA file called “Stolen” with two hidden operationsRead operation on file MarketWrite operation on file StolenExample (cond)Example (cond) Restriction should be enforced on the operations that processes themselves can execute. Mandatory policies provide a way to enforce information flow control through the use of labelsAccess ControlDiscretionary Access ControlAccess Matrix ModelState of Protection SystemImplementation of the Access MatrixVulnerabilities of the Discretionary PoliciesAdditional features of DACDAC – additional features and recent trendsFlexibility is enhanced by supporting different kinds of permissionsPositive vs. negativeStrong vs. weakImplicit vs. explicitContent-basedPositive and Negative PermissionsPositive permissions  Give accessNegative permissions  Deny accessUseful to specify exceptions to a given policy and to enforce stricter control on particular crucial data itemsPositive and Negative Permissions-+Main Issue: ConflictsAuthorization ConflictsMain solutions:No conflictsNegative permissions take precedencePositive permissions take precedenceNothing take precedenceMost specific permissions take precedenceWeak and Strong PermissionsStrong permissions cannot be overwrittenWeak permissions can be overwritten by strong and weak permissionsImplicit and Explicit PermissionsSome models support implicit permissionsImplicit permissions can be derived:by a set of propagation rules exploiting the subject, object, and privilege hierarchiesby a set of user-defined derivation rulesDerivation Rules: ExampleAnn can read file F1 from a table if Bob has an explicit denial for this accessTom has on file F2 all the permissions that Bob hasDerivation rules are a way to concisely express a set of security requirementsDerivation RulesDerivation rules are often expressed according to logic programmingSeveral research efforts have been carried out to compare the expressive power of such languagesWe need languages based on SQL and/or XMLContent-based PermissionsContent-based access control conditions the access to a given object based on its contentThis type of permissions are mainly relevant for database systemsAs an example, in a RDBMS supporting content-based access control it is possible to authorize a subject to access information only of those employees whose salary is not greater than 30KContent-based PermissionsTwo most common approaches to enforce content-based access control in a DBMS are done:by associating a predicate (or a Boolean combination of predicates) with the permissionby defining a view which selects the objects whose content satisfies a given condition, and then granting the permission on the view instead of on the basic objectsDAC models - DBMS vs OSIncreased number of objects to be protectedDifferent granularity levels (relations, tuples, single attributes)Protection of logical structures (relations, views) instead of real resources (files)Different architectural levels with different protection requirementsRelevance not only of data physical representation, but also of their semantics Cost BenefitsSaves about 7.01 minutes per employee, per year in administrative functionsAverage IT admin salary - $59.27 per hourThe annual cost saving is: $6,924/1000; $692,471/100,000Reduced Employee downtime if new transitioning employees receive their system privileges faster, their productivity is increased26.4 hours for non-RBAC; 14.7 hours for RBACFor average employee wage of $39.29/hour, the annual productivity cost savings yielded by an RBAC system: $75000/1000; $7.4M/100,000AgendaAccess Control Discretionary Access ControlMatrix-based modelsGraph-based modelsDiscretionary models specific to databasesGraph-based modelsA graphical model or probabilistic graphical model (PGM) is a probabilistic model for which a graph expresses the conditional dependence structure between random variables. They are commonly used inprobability theory, statistics—particularly Bayesian statistics—and machine learning.Graph-based modelsAccess Control Discretionary Access ControlMatrix-based modelsGraph-based modelsDiscretionary models specific to databases