Secure DBMS design

Week 7OutlineSecure mechanismsThe system R authorization modelSecure DBMS architecturesCommercial productsOutlineSecure mechanismsThe system R authorization modelSecure DBMS architecturesCommercial productsRequirementsDifferent types of access modes.Dynamic authorizationInference controlPolyinstantiationAuditingNo BackdoorsReasonable performanceBasic PrinciplesWell-formed transactionsContinuity of operationSeparation of dutiesDelegation of authorityAuthenticated usersEase of safe useOutlineSecure mechanismsThe system R authorization modelSecure DBMS architecturesCommercial productsThe system R authorization modelSystem R was defined by Griffiths and Wade(1976), revised by Fagin (1978).Developed at the IBM Research Laboratory.Access modes:ReadInsertDeleteUpdateDropThe system R authorization modelGrantEx: The system R authorization modelRevokeThe system R authorization modelExample:CascadeThe system R authorization modelRevocationWith admin optionSYSAUTH tableThe system R authorization model List of X’s remaining incoming grants: List of X’s grants to others: DELETEREAD & INSERTResult:The system R authorization modelViewView owner entitled to drop view but may not exercise all privilegesThe owner of a view has the same rights as on the base tablesThe owner of a view (with the grant option) can grant others access rights on the view.Access rights on base tables, given to the owner of a view after the creation of the view are not added to the view.Access rights on base tables, revoked from the owner of a view, are also removed from the view.Implement modelSYSAUTH & SYSCOLAUTHSYSAUTH: UseridTnameGrantorType: “R” or “V”Read, insert, delete, updateGrantopt: “yes” or “no”Implement modelSYSCOLAUTH: store information on the columns for update privilege.Userid TableColumnGrantorGrantoptExtensionsNon-cascadeCascadeNon-cascadeExtensionsNegative authorizationDeny to access an object.Stronger than positive authorization.Secure mechanismsThe system R authorization modelSecure DBMS architecturesCommercial productsSecure DBMS architecturesTwo modes:System highMultilevelTrusted subjectWoods Hole: [ Integrity lock, Kernelized, Replicated ]System highAll users are cleard to the highest security level.Human must review data before release them.MultilevelTrusted Subject ArchitectureMAC is enforced by itselfWoods Hole Architecture [US Air force Study 1982]MAC enforcement is delegated to Trusted OS.Multilevel[Multilevel] Trusted subjectMultilevel[Multilevel] Trusted subjectSubject having DBMS label are considered trusted subjects and are exempt from TOS mandatory controls.Commercial DBMS: SybaseProsGood securityOverhead minimization in retrieval and update.ConsLarge amount of trusted code required.Multilevel[Multilevel] Woods HoleKernelizedMultiple off-the-shelf DBMS are associated with each TFEs.Trusted OS -> responsible for the physical accesses to data in the database with mandatory protection.Prototype SeaView(1988) &OracleTransform: a multilevel relation into several single-level relations.Recovery: generate mutilevel view.KernelizedProsEasy to implementHigh level assuranceSeparation of data by TOSConsAdditional overheadAs TOS involves to manage data by the security level.Need-to-combine data from multiple level of DBOn higher trusted user’s queryIntegrity lockThe trusted filter would generate a cryptographic checksumCommercial DBMS: TRUDATAExample: checksumIntegrity lockProsDetect modificationsTrojan Horses direct releaseUntrusted DBMSConsRequire key managementInference threatIntegrity lockExample: Relation “EMPLOYEE”Secret: Att= { name }, User-levelTop-Secret: Attr= { proj }NILIntegrity lock Maximal Authorized ViewIntegrity lock Commutative Filter ApproachReplicatedLow data is replicatedPrototype NRL, no commercial DBMS.Pros:Easy to access.Cons:Require synchroniztion algorithmsExpensiveRemarks on secure architecturesSecure mechanismsThe system R authorization modelSecure DBMS architecturesCommercial productsCommercial productsSybase secure serverIngresOracleDB2Commercial productsSybase secure serverObjects: Primary objects: table rows, the smallest objects that can have a security label.Secondary objects: tables, databases.Subjects: users and user groupsAccess control: Verify users’ privileges according to their label.Table: MAC->DACView: DAC->MACAuditing can be configured.Commercial productsIngresSubjects are users and groups.When executing an application a user must enter the role and password for that role.Objects: databases, catalogues, tables, views, procedures. Grant and no Grant Option.Auditdb command for inspecting audits.Commercial productsOracleSubjects can be created, altered and dropped.Granting roles to roles creates hierarchy.Connect privilege to connect to database.Resource privilege to create base tables, grant.DBA privilege to also create users.Special account: Sys, System -> DBA privilege.Public -> basic groupCommercial productsOracleObjects are databases, tables, views, etc. Operations: Select, Insert, Update, Delete, Alter, Index and Reference on tables.Select, Insert, Update and Delete on views.Execute privilege on procedures.Grant option is available.Commercial productsDB2Objects: tables, system catalogueTables: Systables & Syscolumns