Secure DBMS design

1. Week 7 Secure DBMS design

2. Outline • Secure mechanisms • The system R authorization model • Secure DBMS architectures • Commercial products

3. Outline • Secure mechanisms • The system R authorization model • Secure DBMS architectures • Commercial products

4. Requirements • Different types of access modes. • Dynamic authorization • Inference control • Polyinstantiation • Auditing • No Backdoors • Reasonable performance

5. Basic Principles • Well-formed transactions • Continuity of operation • Separation of duties • Delegation of authority • Authenticated users • Ease of safe use

6. Outline • Secure mechanisms • The system R authorization model • Secure DBMS architectures • Commercial products

7. The system R authorization model • System R was defined by Griffiths and Wade(1976), revised by Fagin (1978). • Developed at the IBM Research Laboratory. • Access modes: • Read • Insert • Delete • Update • Drop

8. The system R authorization model • Grant • < s , p , t , ts , g , go > • Ex: <B, select, T, 10, A, yes>

9. The system R authorization model • Revoke

10. The system R authorization model • Example: Cascade

11. The system R authorization model • Revocation • With admin option SYSAUTH table

12. The system R authorization model List of X’s remaining incoming grants: List of X’s grants to others: Result: DELETE READ & INSERT

13. The system R authorization model • View • View owner entitled to drop view but may not exercise all privileges • The owner of a view has the same rights as on the base tables • The 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.

14. Implement model • SYSAUTH & SYSCOLAUTH • SYSAUTH: • Userid • Tname • Grantor • Type: “R” or “V” • Read, insert, delete, update • Grantopt: “yes” or “no”

15. Implement model • SYSCOLAUTH: store information on the columns for update privilege. • Userid • Table • Column • Grantor • Grantopt

16. Extensions • Non-cascade Cascade Non-cascade

17. Extensions • Negative authorization • Deny to access an object. • Stronger than positive authorization.

18. Secure mechanisms • The system R authorization model • Secure DBMS architectures • Commercial products

19. Secure DBMS architectures • Two modes: • System high • Multilevel • Trusted subject • Woods Hole: [ Integrity lock, Kernelized, Replicated ]

20. System high • All users are cleard to the highest security level. • Human must review data before release them.

21. Multilevel • Trusted Subject Architecture • MAC is enforced by itself • Woods Hole Architecture [US Air force Study 1982] • MAC enforcement is delegated to Trusted OS.

22. Multilevel • [Multilevel] Trusted subject

23. Multilevel • [Multilevel] Trusted subject • Subject having DBMS label are considered trusted subjects and are exempt from TOS mandatory controls. • Commercial DBMS: Sybase • Pros • Good security • Overhead minimization in retrieval and update. • Cons • Large amount of trusted code required.

24. Multilevel • [Multilevel] Woods Hole

25. Kernelized • Multiple 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) &Oracle • Transform: a multilevel relation into several single-level relations. • Recovery: generate mutilevel view.

26. Kernelized • Pros • Easy to implement • High level assurance • Separation of data by TOS • Cons • Additional overhead • As TOS involves to manage data by the security level. • Need-to-combine data from multiple level of DB • On higher trusted user’s query

27. Integrity lock • The trusted filter would generate a cryptographic checksum • Commercial DBMS: TRUDATA • Example: checksum

28. Integrity lock • Pros • Detect modifications • Trojan Horses direct release • Untrusted DBMS • Cons • Require key management • Inference threat

29. Integrity lock • Example: Relation “EMPLOYEE” • Secret: Att= { name }, User-level • Top-Secret: Attr= { proj } NIL

30. Integrity lock • Maximal Authorized View

31. Integrity lock • Commutative Filter Approach

32. Replicated • Low data is replicated • Prototype NRL, no commercial DBMS. • Pros: • Easy to access. • Cons: • Require synchroniztion algorithms • Expensive

33. Remarks on secure architectures

34. Secure mechanisms • The system R authorization model • Secure DBMS architectures • Commercial products

35. Commercial products • Sybase secure server • Ingres • Oracle • DB2

36. Commercial products • Sybase secure server • Objects: • Primary objects: table rows, the smallest objects that can have a security label. • Secondary objects: tables, databases. • Subjects: users and user groups • Access control: • Verify users’ privileges according to their label. • Table: MAC->DAC • View: DAC->MAC • Auditing can be configured.

37. Commercial products • Ingres • Subjects 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.

38. Commercial products • Oracle • Subjects 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 group

39. Commercial products • Oracle • Objects 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.

40. Commercial products • DB2 • Objects: tables, system catalogue • Tables: Systables & Syscolumns

41. The End