Docstoc

security

Document Sample
security Powered By Docstoc
					              Chapter 7




           Database Security




8/5/2011      Prof. Ehud Gudes Security Ch 7   1
   Introduction to DB Security
 Secrecy: Users should not be able to see things they are not
   supposed to.
    e.g., a student cannot see other student‟s grades.
 Integrity: Users should not be able to modify things they are not
   supposed to.
    e.g., only instructors can assign grades.
    Also, the DBMS should protect the database from
      non-malicious integrity errors

 Availability: users should be able to see and modify things they are
   allowed to.

        8/5/2011       Prof. Ehud Gudes Security Ch 7                 2
Integrity Problems in Databases
Checks on values –
 single record checks, before and after update checks,
 etc.
Various integrity constraints –
 primary keys, unique checks, foreign keys, etc.
General integrity constraints –
 Constraints, Asserts, Triggers.
Consistency problems as a result of concurrent
 execution of transactions.
Integrity problems as results of system failure –
 Log and Recovery

      8/5/2011    Prof. Ehud Gudes Security Ch 7         3
  Security - Policies and Mechanism

 Policies – general guidelines on authorization in the system,
  examples:
    Students can see their grades
    Only instructors can change grades
 Mechanisms – techniques to enforce the policies
    Access control
    Encryption




                      Prof. Ehud Gudes Security Ch 7
Categories of Security Policies

  Mandatory vs. Discretionary (Need to Know).
  Ownership vs. Administration
  Centralized vs. Distributed
  Close vs. Open
  Name, Content or Context dependent
  Individual, Group or Role based
  Information Flow Control based




                    Prof. Ehud Gudes Security Ch 7
 DAC - The Access Matrix Model


 Subjects
 - users, groups, applications, transactions
 Objects
 - Files, programs, databases, relations, URLs
 Access-types
  - Read, write, create, copy, delete, execute, kill
 Authorization commands
  - enter, remove, transfer
 Authorizers
  - Owners, users, administrators



                    Prof. Ehud Gudes Security Ch 7
 The Access Matrix Model
                                              OBJECTS



                            Subjects                             Files                 Devices



                      S1               S2                F1               F2    D1                D2



                S1                     Call             Read                    Seek
SUBJECTS
                                                        Write


                S2   Send                                                Read                    Rewind



                S3                     Kill             Delete




                                 Compatibility Lists
                                       Access Lists

     8/5/2011         Prof. Ehud Gudes Security Ch 7                                                      7
 Access Control Lists

 The access matrix is too large and too sparse to be practical
 It can be stored by columns:
     Objects have ordered lists of domains that can access them
     Access bits RWX express access to files by users and groups
     Prohibiting access specifically, by owner, can be expressed
      as
         File1: (Amnon,staff,RWX)
         File2: (*,student,R--), (Rachel,*,---)
         File3: (Mike,*,R-X)




       8/5/2011         Prof. Ehud Gudes Security Ch 7              8
The Information Flow Problem of DAC (II)

                           Information Flow
                                                         r: Alice; w: Alice

       User: Alice
                                                              File A
                       Pgm X

                                        Read

                                                         r: Bob; r,w: Alice

       User: Bob            TH
                                           Write
                                                               File B


User Bob can read contents of the file A
copied to file B
       8/5/2011         Prof. Ehud Gudes Security Ch 7                        9
   Mandatory Policy - Bell and LaPadula Model


Objective of the model: trying to keep secrets and avoid illegal
flow

Both subjects and objects are assigned security levels:
Public, Confidential, Secret, Top Secret
dominance relationship between security levels: ‚  ‘

       • Simple Security Property:
         Successful read access: Clearance (S)  Class (O)

        • *-Property:
          Successful write access: Class (O)  Clearance (S)
       8/5/2011      Prof. Ehud Gudes Security Ch 7                10
   Bell and LaPadula Model (2)

The *-property protects information from being ‚written-down‘ along the hierarchy of
sensitivity levels.
                                             O5                 high
                                       (w)
                                             (w)
                                       S2          O4
                            (r)
                                             (r)

                           O3
                    (w)
                          (w)
                   S1             O2
         (r)
                           (r)
                                                                       O   S
       O1                                               low


                  ‚Write‘ if no ‚read‘ to higher classified data!




               8/5/2011            Prof. Ehud Gudes Security Ch 7                  11
  DBMS Discretionary Access
  Control
Based on the concepts of access rights or privileges for
  objects (tables and view), and mechanisms for giving
  users privileges (and revoking privileges).

Creator of a table or a view automatically gets all
  privileges on it.
    DBMS keeps track of who subsequently gains and loses
     privileges, and ensures that only requests from users who
     have the necessary privileges (at the time the request is
     issued) are allowed.



      8/5/2011        Prof. Ehud Gudes Security Ch 7        12
  History of Relational Systems
Codd‟s paper – early 70s
Two research systems: Berkeley Ingres and IBM System
 R – late 70s
SQL was developed based on System R
All relational systems today are SQL (92,99) compatible
Security:
    Ingres – DAC, centralized, Rule-based
    System R – DAC, Distributed, View based
SQL security follows System R security


      8/5/2011     Prof. Ehud Gudes Security Ch 7      13
  Security in INGRES


Centralized, DBA enters authorization rules
The query predicate is combined with the relevant rule
 predicates to derive a modified query
The concept of query modification – partial results are
 possible
Difficult to manage a large group of users and rules
Surprise – new Virtual Private Databases in Oracle follow
  INGRES concepts – also called FGAC – fine-grained
  Access Control
      8/5/2011     Prof. Ehud Gudes Security Ch 7          14
       Protection in Ingres
                                                 DBA


                                              PROTECTION
                                             INTERACTIONS



                                               CONVERT
        QUEL         CONVERT                      TO
User                    TO
        query                                  INTERNAL
                     INTERNAL                    FORM
                       FORM



                     VALIDATE
                       AND
                      MODIFY


                                      SHARED
                                                       PROTECTION
                                     RELATIONS


          8/5/2011        Prof. Ehud Gudes Security Ch 7            15
  Protection in Ingres, cont.
 (Rule 1)        range of E is employee
                  permit E to Jones for
                  retrieve (E.name, E.mgr)
                          where E.dept = „D1‟

 (Rule 2)        range of E is employee
                  permit E to Jones for
                  retrieve (E.name, E.dept, E.mgr)
                          where E.dept = „D1‟

 (Rule 3)        permit E to jones for retrieve (E.name, E.sal)
                         where E.mgr = „jones‟

 (Rule 3)        permit E to jones for retrieve (E.sal)
                         where E.sal < 100000
       8/5/2011         Prof. Ehud Gudes Security Ch 7             16
       The concept of Views – A Window
       over the database


+       Query simplicity            +              Performance
      Multiple table-queries may be                Views may be precompiled and
      expressed simply against a view                 optimized

                                            -      Update restrictions
+     Structural simplicity                      Many views are 'read-only'
      Views can give a user a
      'personalized' interpretation
      of the database


Security – a user sees only the
           portion relevant to him
            8/5/2011           Prof. Ehud Gudes Security Ch 7                     17
    Example Database (1)
The example database scenario


                                                manages
                                      1                          N


                                    date                        function
        ssn
                                                                                     title
       name
                                           N                M
                         Employee                                         Project   subject
        dep
                                               Assignment                           client
       salary                       ssn                           title




              8/5/2011               Prof. Ehud Gudes Security Ch 7                           18
Example Database (2)
              Project
               Title       Subject       Client      Manager
              Alpha      Development       A           124
               Beta       Research         B           125
             Celsius      Production       C           123


  Assignment
   SSN       Title            Employee
   123   Celsius                SSN    Name       Department   Salary
   124       Alpha              123     Bob         Sales      4.0 K
   124       Beta               124    Susan       Research    4,9 K
   125       Alpha              125    Josef      Data Proc.   3,9 K
   125       Beta               126    Calvin     Assembling   6,2 K
   125   Celsius                127    Josef       Research    6,2 K
   126   Celsius


  8/5/2011              Prof. Ehud Gudes Security Ch 7                  19
   Horizontal / Vertical View
    CREATE VIEW view-name                                                        AS query

                                        (-- column_name --)
                                                 ,
Horizontal View                                      earning_little
                                                      SSN       Name            Department       Salary
     (1)    CREATE VIEW earning_little AS             123        Bob              Sales          4.0 K
              SELECT *                                124       Susan            Research        4.9 K
              FROM    Employee                        125       Josef           Data Proc.       3.9 K
              WHERE Salary 5K
                                                     emp
                                                       SSN              Name             Department
Vertical View                                           123             Bob                   Sales
                                                        124             Susan                Research
     (2)    CREATE VIEW emp AS                          125             Josef            Data Proc.
              SELECT SSN, Name, Department              126           Calvin             Assembling
              FROM Employee
                                                        127             Josef                Research



           8/5/2011           Prof. Ehud Gudes Security Ch 7                                              20
 Mixed View (1)
               (3)   CREATE VIEW emp_research AS
                       SELECT SSN, Name, Department FROM Employee
                       WHERE Department = ‚Research‘


               (4)   CREATE VIEW dep_involved AS SELECT Title, Subject, Department
                       FROM     Project, Assignment, Employee
                       WHERE    Employee.SSN = Assignment.SSN AND
                                Assignment.Title = Project.Title


dep_involved
  Title       Subject       Department
 Alpha     Development       Research                emp_research
 Alpha     Development      Data Proc.
                                                        SSN      Name     Department
  Beta       Research        Research
                                                        124      Susan     Research
  Beta       Research       Data Proc.
                                                        127      Josef     Research
 Celsius    Production      Assembling
 Celsius    Production      Data Proc.
 Celsius    Production         Sales


       8/5/2011               Prof. Ehud Gudes Security Ch 7                           21
       Mixed View (2)

(5)   CREATE VIEW dep_avg_salary AS                       dep_avg_salary
        SELECT    Department, Avg (Salary)                                   Avg
                                                           Department
                                                                           (Salary)
        FROM      Employee
                                                              Sales         4,0 K
        GROUP BY Department                                 Research        5,6 K
                                                           Data Proc.       3,9 K
                                                           Assembling       6,2 K


(6)   CREATE VIEW my_employees AS
        SELECT SSN, Name, Department, Salary
                                                       for User ‚123‘
        FROM    Project, Assignment, Employee
        WHERE Employee.SSN = Assignment.SSN AND         SSN      Name      Department   Salary
                                                        126      Calvin    Assembling   6,2 K
                Assignment.Title = Project.Title AND
                                                        125      Josef     Data Proc.   6,2 K
                Manager = USER                          123       Bob         Sales     4,0 K




             8/5/2011            Prof. Ehud Gudes Security Ch 7                             22
Views are ideal for security...


  Views are ideal for security…
    value independent controls             (2)
    value dependent controls               (1), (3), (4)
    statistical controls                   (5)
    context dependent controls             (6)




  8/5/2011       Prof. Ehud Gudes Security Ch 7            23
The View Update problem
How to translate update on a view to
  unambiguous update on the Base tables?
Examples:
Add an employee with salary >5K into view 1
Add an employee to View 2 (null values)
Update Salary in View 5.
Add a new row into View 4
Generally the solution is:
allow updates only on single level views which include the
  primary key and all non-null attributes

      8/5/2011    Prof. Ehud Gudes Security Ch 7        24
 Views and Security

Views can be used to present necessary information
  (or a summary), while hiding details in underlying
  relation(s).
      Given ActiveSailors, but not Sailors or Reserves, we can
       find sailors who have a reservation, but not the bid‟s of
       boats that have been reserved.

 Creator of view has a privilege on the view if (s)he has
  the privilege on all underlying tables.

Together with GRANT/REVOKE commands, views are a
  very powerful access control tool.
       8/5/2011      Prof. Ehud Gudes Security Ch 7            25
Summary – Views and Security

Enable convenient specification and enforcement of
 access to portions of the database, which include any
 horizontal, vertical or join on the Base tables using
 standard SQL
Once a view is defined, the access to it is binary, either
 yes or no
Access control is provided only if access is via the view
Distributed administration: users are owners of the
 views they define and can delegate access further
Views are problematic for update

       8/5/2011     Prof. Ehud Gudes Security Ch 7        26
     Authorization in SQL based systems –
     The GRANT command

GRANT privileges ON object TO users [WITH GRANT OPTION]

 The following privileges can be specified:
      SELECT: Can read all columns (including those added later via ALTER
       TABLE command).
    INSERT(col-name): Can insert tuples with non-null or non-default
       values in this column.
         INSERT means same right with respect to all columns.
    DELETE: Can delete tuples.
    REFERENCES (col-name): Can define foreign keys (in other tables) that
       refer to this column.
 If a user has a privilege with the GRANT OPTION ,can pass privilege on to
  other users (with or without passing on the GRANT OPTION).
 Only owner can execute CREATE, ALTER, and DROP.
    8/5/2011         Prof. Ehud Gudes Security Ch 7                 27
GRANT-Statement

   GRANT            SELECT
                    INSERT
                    DELETE
                    UPDATE
                                 ( column-name )

                                        ,
                        ,
                     ALL PRIVILEGES




   ON       base relation      TO           user-name            
            view relation                   PUBLIC      WITH
                                                        GRANT
                                                        OPTION




 8/5/2011             Prof. Ehud Gudes Security Ch 7                 28
REVOKE in SQL92


    REVOKE                    SELECT
              GRANT           INSERT
              OPTION          DELETE
              FOR             UPDATE
                                         (     column-     )
                                               name
                                                   ,
                                   ,
                              ALL PRIVILEGES




    ON       table-name     FROM       user-name         RESTRICT
             view-name                  PUBLIC           CASCADE
                                            ,




  8/5/2011             Prof. Ehud Gudes Security Ch 7               29
 Access Privileges in different
           DBMSs

ANSI / ISO SQL Standard     SELECT
                            INSERT
                            DELETE
                            UPDATE
                            GRANT

DB2, Oracle                 ALTER
                            CREATE INDEX

Sybase, Sql Server          EXTENDED SELECT
                            EXECUTE

DB2                         USE Tablespace




 8/5/2011             Prof. Ehud Gudes Security Ch 7   30
GRANT and REVOKE of Privileges

 GRANT       INSERT, SELECT ON Employees TO Horatio
      Horatio can query Employees or insert tuples into it.

 GRANT DELETE ON        Employees TO Yuppy WITH GRANT
  OPTION
      Yuppy can delete tuples, and also authorize others to
       do so.

 GRANT UPDATE Salary ON Employees              TO Dustin
      Dustin can update (only) the salary field of Employees
       tuples.


   8/5/2011         Prof. Ehud Gudes Security Ch 7             31
 Protection in System R [J14]
                                                 .
GRANT READ ON EMP TO B WITH GRANT OPTION        A:
GRANT READ ON EMP TO C WITH GRANT OPTION        A:
                 GRANT READ ON EMP TO X         B:
                 GRANT READ ON EMP TO X         C:




    8/5/2011   Prof. Ehud Gudes Security Ch 7        32
        ‫‪Protection in System R‬‬



‫בדוגמה זו רואים כי ‪ X‬קיבל זכויות משני גורמים מ-‪ B‬ומ-‪ C‬ולכן שלילת הזכויות מ-‪ B‬אינה‬
                      ‫גורמת בהכרח שלילת הזכויות מ-‪ .X‬אם לדוגמה נבצע את הפקודה‬
                                  ‫:‪A‬‬        ‫‪REVOKE READ ON EMP FROM B‬‬
  ‫אזי במקרה של קיום שלילה רקורסיבית נקבל את הגרף באיור 6.7א' ובמקרה של אי קיום‬
                                       ‫שלילה רקורסיבית נקבל את הגרף באיור 6.7ב'.‬




              ‫1102/5/8‬        ‫7 ‪Prof. Ehud Gudes Security Ch‬‬                    ‫33‬
The privilege dependency graph


               a1(_SYSTEM, A, SELECT, T, yes, 10)



  a2(A, B, SELECT, T, yes, 20)    a3(A, C, SELECT, T, yes, 30)

  a4(B, D, SELECT, T, yes, 40)    a6(C, D, SELECT, T, yes, 60)



                  a7(D, F, SELECT, T, yes, 70)
                                                    B

                                              2         4
  a5(D, E, SELECT, T, yes, 50)                              D       E   8   G
                                                                5
                                          A
  a8(E, G, SELECT, T, yes, 80)
                                              3         6       7

                                                    C               F



  8/5/2011         Prof. Ehud Gudes Security Ch 7                               34
     REVOKE IN SYSTEM R
          B                                                          B

     2        4
                                                                 2
                    D           E         G                                  D
                            5       8
 A                                                         A

     3        6         7                                        3       6       7

         C                      F                                    C               F




Revoking a4 (with CASCADE option) will succeed. Authorization a7

 will not be revoked, because it is supported by a6, but a5 and a8

  Will be revoked. The privilege dependency graph will change.
         8/5/2011               Prof. Ehud Gudes Security Ch 7                       35
        REVOKE in System R
REVOKE: procedure (grantee, privilege, table, grantor);
   comment turn off the grantee‟s authorization for privilege obtained from granter;
   set privilege = 0 in the (grantee, table, grantor) tuple in SYSAUTH;
   comment find the minimum timestamp for the grantee‟s remaining grantable
         privilege on table;
   m  current timestamp;
   for each granter u such that (grantee, privilege, table, u, grantable) is in
         SYSAUTH do if privilege  0 and privilege < m
             then m  privilege;
   comment revoke grantee‟s grants of privilege on table which were made before
   time m;

   For each user u such that (u, privilege, table, grantee) is in SYSAUTH do if
        privilege < m
            then REVOKE (u, privilege, table, grantee) ;
   return
   end REVOKE

              8/5/2011         Prof. Ehud Gudes Security Ch 7                     36
      Protection in System R, cont.
Suppose that at time t=35, B issues the command REVOKE ALL RIGHTS ON EMPLOYEE
   FROM X. Clearly the (X, EMPLOYEE, B) tuple must be deleted from SYSAUTH. In
   order to determine which of X‟s grants of EMPLOYEE must be revoked, we form a list
   of X‟s remaining incoming grants:
   USERID               TABLE        GRANTOR         READ         INSERT        DELETE
      X            EMPLOYEE              A            15           15             0
      X            EMPLOYEE              B            20            0             20
      Y            EMPLOYEE              X            25           25             25
      X            EMPLOYEE              C            30            0             30

As well as a list of X‟s grants to others:

                   TABLE              READ           INSERT        DELETE

                 EMPLOYEE            {15, 30}         {15}          {30}


The grant of the DELETE privilege by X to Y at time t=25 must be revoked because his
earliest remaining DELETE privilege was received at time t=30. But X‟s grants of READ
and INSERT are allowed to remain because they are still “supported” by incoming grants
which occurred earlier in time.

             8/5/2011            Prof. Ehud Gudes Security Ch 7                        37
  GRANT/REVOKE on Views

If the creator of a view loses the SELECT privilege on an
  underlying table, the view is dropped!

If the creator of a view loses a privilege held with the
  grant option on an underlying table, (s)he loses the
  privilege on the view as well; so do users who were
  granted that privilege on the view!




       8/5/2011    Prof. Ehud Gudes Security Ch 7           38
              Revoking Access on Views
                     - System R
 REVOKE :       procedure (grantee, table, grantor) ;
                 delete the (grantee, table, grantor) tuple in SYSAUTH;
                 for each u such that (u, table, grantee) is in SYSAUTH do
                    REVOKE (u, table, grantee) ;
                 for each view such that (table, view, grantee) is in
                    SYSUSAGE do DROP (view) ;
                 return ;
                 end REVOKE ;

 DROP :         procedure (view) ;
                 delete the view definition from the system ;
                 for each u1 and u2 such that (u1, view, u2) is in
                    SYSAUTH do REVOKE (u1, view, u2) ;
                 for each v and u such that (view, v, u) is in SYSUSAGE do
                 DROP (v) ;
                 return ;
                 end DROP ;
           8/5/2011        Prof. Ehud Gudes Security Ch 7              39
  REVOKE in SQL

RESTRICT – accept only if there are no privileges
  resulted SOLELY from the revoked command, otherwise
  reject

CASCADE – remove privileges recursively as in System
  R, but do not consider time!, that is, if a privilege was
  granted to B by A, and A‟s rights were revoked, but
  LATER A was given these rights independently, then
  don‟t revoke B‟s rights - this is equivalent to saying that
  there is a path from the “System” node



      8/5/2011     Prof. Ehud Gudes Security Ch 7         40
      Protection in SQL
GRANT SELECT ON Sailors TO Art WITH GRANT OPTION      (executed   by Joe)
GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION      (executed   by Art)
GRANT SELECT ON Sailors TO Art WITH GRANT OPTION      (executed   by Bob)
GRANT SELECT ON Sailors TO Cal WITH GRANT OPTION      (executed   by Joe)
GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION      (executed   by Cal)
REVOKE SELECT ON Sailors FROM Art CASCADE             (executed   by Joe)




           8/5/2011       Prof. Ehud Gudes Security Ch 7                    41
Protection in SQL, cont.

             System (System, Joe, Select on Sailors, Yes)




              Joe                                     Art




              Cal                                    Bob



  8/5/2011          Prof. Ehud Gudes Security Ch 7          42
Protection in SQL, cont.
     What happens if Joe revokes access from Cal




  8/5/2011        Prof. Ehud Gudes Security Ch 7   43
The privilege dependency graph


               a1(_SYSTEM, A, SELECT, T, yes, 10)



  a2(A, B, SELECT, T, yes, 20)    a3(A, C, SELECT, T, yes, 30)

  a4(B, D, SELECT, T, yes, 40)    a6(C, D, SELECT, T, yes, 60)



                  a7(D, F, SELECT, T, yes, 70)
                                                    B

                                              2         4
  a5(D, E, SELECT, T, yes, 50)                              D       E   8   G
                                                                5
                                          A
  a8(E, G, SELECT, T, yes, 80)
                                              3         6       7

                                                    C               F



  8/5/2011         Prof. Ehud Gudes Security Ch 7                               44
SQL - REVOKE with RESTRICT
option
                    B

                         4
                2
                              D             E            G
                                      5              8
         A

                3                 7


                    C                       F




  Revoke of a4 with RESTRICT option will fail! If we have
  added a6,
  then it would not have failed!

     8/5/2011       Prof. Ehud Gudes Security Ch 7           45
    What may be useful and is not
    supported in SQL92?

• Negative authorizations

• Non cascading revoke

          B                                                   B

    2          4
                     D           E         G            2                 5
                                     8                                            E        G
                             5                                                        8
A                                                  A                  D
    3          6         7                             3                      7
                                                                  6

          C                      F                            C                   F




          8/5/2011               Prof. Ehud Gudes Security Ch 7                           46
  Protection in SQL, cont.
Why needs SELECT right with Integrity constraints?
May infer values from non permitted table!

  CREATE TABLE Sneaky (maxsalary INTEGER,
                       CHECK ( maxsalary >=

                           ( SELECT MAX (S.salary )
                             FROM Employees         S )))




     8/5/2011   Prof. Ehud Gudes Security Ch 7         47
  Protection in SQL, cont.

   Why SELECT right is not sufficient?
Since owner rights may be restricted (cannot delete rows)!
Needs explicit REFERENCE right

CREATE TABLE Assignments (project CHAR (10) NOTNULL,
                    SSN INTEGER,
                     day DATE,
                     PRIMARY KEY (SSN, day),
      FOREIGN KEY (SSN) REFERENCES Employees
     ON DELETE NO ACTION
      8/5/2011     Prof. Ehud Gudes Security Ch 7       48
    Differences Between System R
              and SQL-92
New privileges – REFERENCE, USAGE
CASCADE or RESTRICT on Revoke
CASCADE different then System R – not time-stamp
  based

Precise definitions for Rights on views
  E.g. the impact of adding/removing a right to/from the
  base tables

Authorization-Ids (for programs), Groups and Roles
      8/5/2011     Prof. Ehud Gudes Security Ch 7          49
  Role-Based Authorization

In SQL-92, privileges are actually assigned to
  authorization ids, which can denote a single user or a
  group of users.

In SQL:1999 (and in many current systems), privileges
  are assigned to roles.
      Roles can then be granted to users and to other roles.
      Reflects how real organizations work.
      Illustrates how standards often catch up with “de facto”
       standards embodied in popular systems.



        8/5/2011      Prof. Ehud Gudes Security Ch 7              50
   Roles and Permissions
Medical_Staff:      collectively, responsible for all aspects of direct patient
                    care.

Nurse:              Direct involvement with patient care on a daily basis.

Physician:          Handle the medical needs (diagnosis, treatment, etc.)
                    for patients.

Pharmacists:        Control the supply and distribution of all drugs throughout
                    the hospital.

Technician:         Provide a variety of medical testing support for Patients.

Therapist:          Evaluate patients and develop treatment plans for therapy.

Staff_RN:           Administer direct care to patients and implement the
                    physician treatment plan.
         8/5/2011           Prof. Ehud Gudes Security Ch 7                        51
   Roles and Permissions, cont.
Discharge_Plug: Link between patients and outside agencies for care after
                       discharge.

Education:             Educate both the nursing staff and patients regarding
                       new treatment and self care.

Manager:               Responsible for the day-to-day operation of a nursing
                       unit

Director:              (For Physician or Pharmacist) Responsible for the day-to-
                       day operation of their respective department/medical
                       service.

Private:               the physician within his/her office/private–practice setting.
Attending:             A physician that hes privileges to admit and treat patients
                       at a hospital.

            8/5/2011          Prof. Ehud Gudes Security Ch 7                    52
        The User-Role Definition Hierarchy
                            Users
Medical Staff                                                Support Staff              Other




Nurse    Physician    Pharmacist    Technician   Therapist       Support      Patient    Spouce




                                                  Prepare room   Volunteer   Security



                User Types, User Classes and Selected User Roles


                8/5/2011            Prof. Ehud Gudes Security Ch 7                              53
  Role-Based Models

RBAC0 – Users, Roles, Permissions, Sessions
RBAC1 – RBAC0 + Role-hierarchies
RBAC2 – RBAC0 + Constraints
RBAC3 – RBAC0 + Role-hierarchies + Constraints



      8/5/2011    Prof. Ehud Gudes Security Ch 7   54
RBAC0

                    .‫המודל הבסיסי עליו מתבססים שאר המודלים‬


                User                        Permission
             assignment                     assignment
 Users          (UA)           Roles           (PA)      Permissions
  (U)                           (R)                          (P)




             Sessions
               (S)




  8/5/2011           Prof. Ehud Gudes Security Ch 7
RBAC1

                                                  .‫-ים‬Role ‫היררכיית‬

                           Role hierarchy
                               (RH)


                User                        Permission
             assignment                     assignment
   Users        (UA)           Roles           (PA)      Permissions
    (U)                         (R)                          (P)




             Sessions
               (S)




  8/5/2011       Prof. Ehud Gudes Security Ch 7
RBAC1

                                                 :‫-ים‬Role ‫ היררכיה של‬
                                                 .‫ קשר אב ובן‬
                                 .‫ הרשאות אפקטיביות וישירות‬

                      Admin
                [Read,Test,Develop]
         Developer                       QA
       [Read,Develop]                [Read,Test]


                      Employee
                       [Read]


  8/5/2011      Prof. Ehud Gudes Security Ch 7
RBAC1

                                                     .‫הגבלת ירושה‬


    Developer'                    Admin
[Read,Develop,Build]        [Read,Test,Develop]
                  Developer                       QA
                [Read,Develop]                [Read,Test]


                                Employee
                                 [Read]




   8/5/2011       Prof. Ehud Gudes Security Ch 7
RBAC2

                                                          ‫מודל האילוצים‬
                                                    .‫-ים מנוגדים‬Role 


                User                         Permission
             assignment                      assignment
  Users         (UA)          Roles             (PA)       Permissions
   (U)                         (R)                             (P)




             Sessions
               (S)

                                      Constranits




  8/5/2011         Prof. Ehud Gudes Security Ch 7
RBAC3

                                                            :‫המודל המשולב‬
                                            .Roles ‫ אילוצים והיררכיית‬
                           Role hierarchy
                               (RH)


                User                           Permission
             assignment                        assignment
  Users         (UA)           Roles              (PA)        Permissions
   (U)                          (R)                               (P)




             Sessions
               (S)

                                        Constranits




  8/5/2011         Prof. Ehud Gudes Security Ch 7
  Constraints in RBAC – Separation
  of duties

Conflicts between Permissions – conflicting permissions
 cannot be in the same Role or in two roles with a
 common ancestor
Conflicts between Roles – the same user cannot be in
 two conflicting roles
Conflicting users
Static constraints – max. number of roles per user,
 permissions per role, etc
Dynamic constraints – session dependent

      8/5/2011     Prof. Ehud Gudes Security Ch 7       61
                              ‫המודל האדמיניסטרטיבי‬

           ‫‪‬הפרדה בין ‪ Role‬רגיל ל-‪ Role‬אדמיניסטרטיבי.‬

                                     ‫‪‬השמת משתמש ל-‪.Role‬‬

                                      ‫‪‬השמת הרשאה ל-‪.Role‬‬

                                         ‫‪‬השמת ‪ Role‬ל-‪.Role‬‬




‫1102/5/8‬     ‫7 ‪Prof. Ehud Gudes Security Ch‬‬
                    ‫השמת משתמשים ל-‪-Role‬ים‬

                                        ‫‪‬הענקת ‪ Role‬למשתמש:‬
 ‫‪ ‬הגדרת תחומי אחריות של ‪ Role‬אדמיניסטרטיבי על ידי היחס‬
                                         ‫‪.can_assign‬‬

                                        ‫‪‬שלילת ‪ Role‬ממשתמש:‬
 ‫‪ ‬הגדרת תחומי אחריות של ‪ Role‬אדמיניסטרטיבי על ידי היחס‬
                                          ‫‪.can_revoke‬‬
           ‫‪ ‬שלילה חלשה – ‪ Role‬אינו נשלל כתוצאה מירושה.‬
                      ‫‪ ‬שלילה חזקה – שלילת כל עץ הירושה.‬




‫1102/5/8‬      ‫7 ‪Prof. Ehud Gudes Security Ch‬‬
‫דוגמא להיררכית ‪-Role‬ים אדמיניסטרטיביים‬




‫1102/5/8‬   ‫7 ‪Prof. Ehud Gudes Security Ch‬‬   ‫46‬
            ‫תחום אחריות של‬
‫-ים אדמיניסטרטיביים‬Role ‫הדוגמא להיררכיית‬

      Role       Role             ‫קבוצת‬         Role ‫טווח‬
 ‫תנאי מוקדם אדמיניסטרטיבי‬       ‫ - ים‬Role
     PSO1         ED         {E1,PE1,QE1}       [E1, PL1)

     PSO2         ED         {E2,PE2,QE2}       [E2,PL2)

      DSO         ED           {PL1,PL2}        (ED,DIR)

      SSO          E               {ED}         [ED,ED]

      SSO         ED              {DIR}         (ED,DIR]



 8/5/2011      Prof. Ehud Gudes Security Ch 7               65
               ‫תחום אחריות של‬
   ‫הדוגמא להיררכיית ‪-Role‬ים אדמיניסטרטיביים‬
   ‫‪‬מהטבלה אנו מבינים של-‪ Role‬האדמיניסטרטיבי 1‪ PSO‬לדוגמא, יש‬
                             ‫סמכויות השמת ‪ – Role‬ים מקבוצה‬
                 ‫}1‪ {E1,PE1,QE‬לכל משתמש שחבר ב- ‪ED ROLE‬‬

    ‫‪‬דרך נוחה יותר לרשום קבוצת ‪ – Role‬ים היא על ידי שימוש בטווח‬
                                                   ‫‪ – Role‬ים.‬
         ‫נשתמש בסימון טווח )‪ (range notation‬על מנת לסמן טווח‬
                                                   ‫‪ – Role‬ים:‬
‫}‪(x,y) = {r ∈ R|x  r  r > y} [x,y] = {r ∈ R|x  r  r  y‬‬
‫}‪(x,y) = {r ∈ R|x > r  r > y} (x,y] = {r ∈ R|x > r  r  y‬‬



      ‫1102/5/8‬     ‫7 ‪Prof. Ehud Gudes Security Ch‬‬         ‫66‬
Roles in SQL99
 New in SQL99; benefits:
   Simplifies definition of complex sets of privileges

 Roles are created
   CREATE ROLE Auditor
   CREATE ROLE AuditorGeneral

 Roles may be assigned to users & roles
   GRANT Auditor TO AuditorGeneral
   WITH ADMIN OPTION
   GRANTED BY CURRENT ROLE

   GRANT Auditor TO Smith

 Controllable whether to grant as user or role
   8/5/2011       Prof. Ehud Gudes Security Ch 7          67
   Roles in SQL99, cont.
Roles (like users) may own objects
As to users, privileges may be granted to roles
  Grant INSERT ON TABLE Budget TO Auditor
  This privilege also among privileges of AuditorGeneral

A role R identifies a set of privileges:
  Those directly granted to R
  Those of the roles granted to R




       8/5/2011     Prof. Ehud Gudes Security Ch 7      68
   Roles in SQL99, cont.
 At any time there is at least a valid current user or a valid current
  role.
 Current user can be set
  SET SESSION AUTHORIZATION „JDOE‟
 Current role can be set or invalidates
  SET ROLE Auditor
 Operations (e.g. INSERT) determine the kind of required privileges
  Often: union of user‟s and role‟s privileges
 Session context maintains stack of user and role identifier pairs
  New pair is pushed when externally invoked procedure is
  executed
  Temporarily makes client module identifier the current user
  Enables invoker‟s rights in a limited fashion

        8/5/2011        Prof. Ehud Gudes Security Ch 7                    69
  Advantages of RBAC
Convenient representation and mapping of the
 organization structure
Convenient distribution of the administration of Roles
Easier definition and understanding of the security policy
 of the organization
Role-hierarchy and inheritance of permissions eases
 administrator job
Changes in user roles are simple and controllable
Sessions allow the same user different roles in different
 contexts
Grouping multiple users to roles allow easier control of
 their permissions
      8/5/2011     Prof. Ehud Gudes Security Ch 7        70
 Security in Object-Oriented Databases

Composition hierarchy [K]
Generalization hierarchy [K]
Explicit and implicit authorization [K]
Strong and weak authorization [K]
Inheritance – which authorizations are inherited? [G]
Algorithm for evaluation [G]
Negative authorization [G]



      8/5/2011     Prof. Ehud Gudes Security Ch 7        71
     Database Granularity Hierarchy
                                              System [MCC]


                       database [Inventory]            database [CAD]        Database…




class [vehicle]         class [automobile]       class [4-wheel-vehicle]         class [Motor-Vehicle]




        instance [1]                    instance [2]           Instance…             instance [100]




   Attribute-value [Weight]                                   Attribute-value…


                                    Database Granularity Hierarchy
             8/5/2011               Prof. Ehud Gudes Security Ch 7                                    72
Class Hierarchy


                                 Vehicle
                     IS-A                   IS-A

             4-Wheel-Vehicle                 Motor-Vehicle

                     IS-A                   IS-A
                               Automobile




  8/5/2011            Prof. Ehud Gudes Security Ch 7         73
     Implicit Authorization
                                                 System [MCC]


                        database [Inventory]              database [CAD]        Database…




class [vehicle]         class [automobile]          class [Motor-Vehicle]




        instance [1]                       instance [2]           Instance…             instance [100]




   Attribute-value [Weight]                                      Attribute-value…



                  Explicit Authorization                                            Implicit Authorization
             8/5/2011                Prof. Ehud Gudes Security Ch 7                                      74
Implicit Weak Authorization with
        Weak Exceptions




 8/5/2011   Prof. Ehud Gudes Security Ch 7   75
Implicit Weak Authorization with
       Strong Exceptions




 8/5/2011   Prof. Ehud Gudes Security Ch 7   76
Security in OO Databases




  8/5/2011   Prof. Ehud Gudes Security Ch 7   77
     A University Database
IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 6, NO. 2, APRIL 1994


                                            Person
                                           A        G


          SSN               Name               Student              Teacher
                                               A        G                A



                                 Year              Foreign                Course
                                                   Student
                                                        A

                                           Visa

  G Generalization Association                                       Defined Attribute
  A Aggregation Association                                          Object Class
           8/5/2011             Prof. Ehud Gudes Security Ch 7                           78
                   Effective Structure of the
                      University Database
  IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 6, NO. 2, APRIL 1994

                                             Person
                                             A        G


            SSN                Name              Student              Teacher
                                                 A        G                A



          SSN         Name         Year              Foreign        SSN            Name         Course
                                                     Student
                                                          A


       SSN          Name          Year                    Visa
                                                                                   Defined Attribute

                                                                                   Object Class
G Generalization Association
A Aggregation Association                                                          Inherited Attribute
             8/5/2011             Prof. Ehud Gudes Security Ch 7                                     79
  Example Policies
For example, consider the graph of the second figure.
  Assume the following authorization rules are defined:

  R1: (SA, Read, S.SSN) – The Student Advisor can read
      SSN of students.
  R2: (FSA, Read, (FS.SSN, FS.Visa)) – The Foreign
      Student Advisor can read SSN and visa of foreign
      students.




      8/5/2011     Prof. Ehud Gudes Security Ch 7         80
  Example Policies, cont.
A Student Advisor (SA) could have access to SSN‟s of all
  students (P1), but no access to their visas (P3); a
  Foreign Student Advisor (FSA) could have access to
  visas but only to SSN‟s of Foreign Students (P2).




      8/5/2011     Prof. Ehud Gudes Security Ch 7          81
   Example Policies, cont.
Q1:    read SSN for all students
Q2:    read SSN and visa for all foreign students

According to these policies, we expect the following behavior as
  a result of the evaluation of the indicated requests:

  (SA, Q1)= (SA, Read, S.SSN) – All SSN‟s can be read
       (Policy P1)

  (SA, Q2)= (SA, Read, {FS.Visa, FS.SSN}) – Only SSN‟s of
       foreign students are to be read and not their visas
       (Policy P3)


       8/5/2011      Prof. Ehud Gudes Security Ch 7           82
        Evaluating Security


            Query       Query                            New
Query                                   Access                                   Query
                                                                   Optimizer
          Compiler      Graph          Evaluation
                                                       Structure                 Code




            Data                      Authorization                            Database
         Descriptions                    Rules




                                  Evaluation Architecture


           8/5/2011             Prof. Ehud Gudes Security Ch 7                    83
    Query Graphs

   Student     A           SSN                                   Person
                                                                    G
      Query Graph for Q1



                                                                 Student
                                                                    G
        Foreign Student
                   A


    Visa               SSN                                    Foreign Student



Query Graphs for queries Q1 an Q2             Query Security Graphs for the Example

           8/5/2011          Prof. Ehud Gudes Security Ch 7                     84
Evaluation Results
Case 1: (SA, Q1) = (SA, Read, S.SSN).
The algorithm finds rule R1 and therefore gives SA acess
  to all SSN‟s.

Case 2: (SA, Q2) = (SA, Read, {FS.SSN, FS.Visa}).
The algorithm first looks at node FS and cannot find any
  rules.then it looks at node S. Now it updates AT by
  removing attribute visa, since it is not known at this
  node and therefore no rule can reference it. Now it finds
  the rule (SA, R, S.SSN), and since obviously S includes
  FS it allows access to all SSN‟s for foreign students but
  not to their visa‟s.
      8/5/2011     Prof. Ehud Gudes Security Ch 7          85
  Evaluation Results, cont.
Case 3: (FSA, Q1) = (FSA, Read, S.SSN).
The algorithm first looks at S and cannot find any rules.
  Then it looks at P and cannot find any rules. Now it goes
  downwards and finds R2. It updates AT_yes with
  FS.SSN and therefore allows access to SSN‟s of foreign
  students only.

Case 4: (FSA, Q2) = (FSA, Read, {FS.SSN, FS.Visa}).
The algorithm looks at FS, finds rule R2 and allows access
  to both SSN‟s and visas.
The above algorithm scans the entire security graph for
  each individual query node. Therefore , its worst-case
  complexity is O(nmk).
      8/5/2011     Prof. Ehud Gudes Security Ch 7          86
          OO Security Administration
                                            Academic Institute
                                                    A
SSN

                A   Person                      Section                      Department
                        G                          A
Name



          Student              Teacher                     Enrollment
            G                      A



      Foreign Student              Course
            A
                                                   C1
                                                                 A Security Context in the
   Visa                                                            University database
       8/5/2011              Prof. Ehud Gudes Security Ch 7                               87
  Mandatory Access Control

Based on system-wide policies that cannot be changed
  by individual users.
      Each DB object is assigned a security class.
      Each subject (user or user program) is assigned a
       clearance for a security class.
      Rules based on security classes and clearances govern
       who can read/write which objects.

Most commercial systems do not support mandatory
  access control. Versions of some DBMSs do support it;
  used for specialized (e.g., military) applications.


        8/5/2011     Prof. Ehud Gudes Security Ch 7            88
  Why Mandatory Control?

Discretionary control has some flaws, e.g., the Trojan
  horse problem:
      Dick creates Horsie and gives INSERT privileges to Justin
       (who doesn‟t know about this).
      Dick modifes the code of an application program used by
       Justin to additionally write some secret data to table
       Horsie.
      Now, Dick can see the secret info.

The modification of the code is beyond the DBMSs
  control, but it can try and prevent the use of the
  database as a channel for secret information.
        8/5/2011      Prof. Ehud Gudes Security Ch 7           89
   Bell-LaPadula Model
Objects (e.g., tables, views, tuples)
Subjects (e.g., users, user programs)
Security classes:
      Top secret (TS), secret (S), confidential (C), unclassified
       (U): TS > S> C > U

Each object and subject is assigned a class.
      Subject S can read object O only if class(S) >= class(O)
       (Simple Security Property)
      Subject S can write object O only if class(S) <= class(O)
       (*-Property)
        8/5/2011       Prof. Ehud Gudes Security Ch 7                90
   Intuition
Idea is to ensure that information can never flow from a
  higher to a lower security level.

E.g., If Dick has security class C, Justin has class S, and
  the secret table has class S:
      Dick‟s table, Horsie, has Dick‟s clearance, C.
      Justin‟s application has his clearance, S.
      So, the program cannot write into table Horsie.

The mandatory access control rules are applied in
  addition to any discretionary controls that are in effect.

        8/5/2011      Prof. Ehud Gudes Security Ch 7       91
  Multilevel Relations

                   bid        bname          color        class
                   101         Salsa          Red           S
                   102         Pinto        Brown           C

Users with S and TS clearance will see both rows; a user
 with C will only see the 2nd row; a user with U will see no
 rows.
If user with C tries to insert <101,Pasta,Blue,C>:
      Allowing insertion violates key constraint
      Disallowing insertion tells user that there is another object
       with key 101 that has a class > C!
      Problem resolved by treating class field as part of key.
        8/5/2011         Prof. Ehud Gudes Security Ch 7           92
Jajodia / Sandhu Model (Sigmod’91)
                     Jajodia / Sandhu Model (Sigmod’91)


A MLS relation consists of a state-invariant multilevel relation schema

                     RS (A1, C1, …, An, Cn, TC),


(where each Ai is an attribute over a dom(ai), each Ci is classification
for Ai and TC is is the tuple-class)

And of a collection of state-dependant relation instances R, one for
each access class c. A relation instance is denoted by
Rc (A1, C1, …, An, Cn, TC) and consists of a set of distinct tuples of the
form (a1, c1, …, an, cn, tc) where each
ai  dom (Ai), c  ci, ci  [Li, Hi], and tc = lub {ci, i=1..n}.


       8/5/2011        Prof. Ehud Gudes Security Ch 7                  93
    MLS-Prototype systems

Sea View
(SRI International, Oracle, Gemsos)
MLS relational datamodel, supports polinstentiation on db-, relation- , tupel-
and attribute levels.

LDV (LOCK Data Views)
(Honeywell SCTC, MITRE)
Extended relational data model, polyinstatiation on tuple level. Supports
application dependent and non application dependent integrity rules.




         8/5/2011         Prof. Ehud Gudes Security Ch 7                         94
     Jajodia - Formal Integrity Rules

A Database D;
A relation R within the database D;
The primary key for a tuple r within the relation R;
The attribute i, identifying the element ri within the tuple r.
To get through to the element ri, the following must hold:
       lab(D)lab(R) lab(ri)
Otherwise, you could be barred access to an element you are
  entitled to see. In convention, a user who has access to an
  element of r must have access to its primary key.Therefore:
                lab(rk) lab(ri)
         8/5/2011        Prof. Ehud Gudes Security Ch 7      95
  Jajodia - Formal Integrity Rules, cont.

Rule Multi-level entity integrity: no component of a
  primary key of a base relation may be null. All
  components of a primary key of a base relation have the
  same access class. In a base relation, the access class
  of all other data values in a tuple dominates the access
  class of the primary key of that tuple.




      8/5/2011     Prof. Ehud Gudes Security Ch 7      96
   Formal Integrity Rules, cont.

Rule Multi-level reference integrity: a tuple referenced by
  a foreign key has to exist. The access class of the
  foreign key dominates the access class of the
  corresponding primary key.

Rule The access class of a view dominates the access
  classes of all relations used in the definition of the view.

Rule The access class of a tuple dominates the access
  classes of all attributes in the tuple.


       8/5/2011     Prof. Ehud Gudes Security Ch 7         97
                     Multi-level Relation
Flight [Fl_Class]    Dest. [De_Class] Seats [Se_Class]        [Tuple_Class]


 CA909      [C]         H.K.   [C]            7      [C]           [C]



 AX301     [U]          K.L.   [U]            2      [U]           [U]



 GR555      [U]         L.A.   [C]            11      [C]          [C]


       Figure 15.1       The Relation Bookings with Primary Key Flight

          8/5/2011        Prof. Ehud Gudes Security Ch 7                 98
Multi-level Relation – view of C user

   Flight [Fl_Class]      Dest. [De_Class] Seats [Se_Class]


     CA909      [C]           H.K.     [C]             7    [C]



     AX301      [U]           K.L.    [U]              2    [U]



     GR555      [U]           L.A.     [C]             11   [C]


  Figure 15.1         The Relation Bookings with Primary Key Flight

   8/5/2011           Prof. Ehud Gudes Security Ch 7                  99
Multi-level relation – view of U
user

         Flight              Dest                  Seats


         AX301                K.L.                  2



         GR555                 --                   --



  Figure 15.2     List of Non-Confidential Data from fig. 15.1
                  Accessible to Unclassified User



  8/5/2011        Prof. Ehud Gudes Security Ch 7                 100
   Why Poly-instantiation?
A low user tries to add information on flight CA909.
   If refused – inference, if accepted - violation of
    primary key constraint
A low user tries to update information on flight GR555.
  If refused – inference, if accepted - violation of
    functional dependency
A high user attempt to change destination of flight
 AX301
   If refused – restricts access, if accepted - violation of
    functional dependency
Solution: accept and include tuple class as part of the
 primary key!.
       8/5/2011     Prof. Ehud Gudes Security Ch 7        101
    Polyinstatiated table after User U
    update
Flight [Fl_Class]    Dest. [De_Class] Seats [Se_Class]         [Tuple_Class]

 CA909      [C]         H.K.   [C]            7      [C]            [C]


 AX301     [U]          K.L.   [U]            2      [U]            [U]


 GR555      [U]         L.A.   [C]            11      [C]           [C]


 GR555      [U]         N.Y.   [U]            0      [U]            [U]


    Figure 15.4       Updated Version of Table Data Given in Figure 15.1.

          8/5/2011        Prof. Ehud Gudes Security Ch 7                    102
Polyinstatiation Cont.
             Flight          Dest            Seats

             CA909           H.K.                  7


             AX301           K.L.                  2


             GR555           L.A.              11


             GR555           N.Y.                  0


 Figure 15.5      Data Accessible to Confidential User


  8/5/2011        Prof. Ehud Gudes Security Ch 7         103
 Subsumption



If user view has a null in U attribute and User C update it
 with non-null value, the C tuple subsumes the U tuple
 and only one tuple is visible to C




     8/5/2011     Prof. Ehud Gudes Security Ch 7        104
  Polyinstantiation integrity
Polyinstantiation integrity       If two tuples in a base
  relation have the same primary key and the respective
  entries for some attribute have the same access class,
  then also the data values for this attribute are the same.
  If two tuples of a base relation have the same primary
  key and if there are some attributes where the
  respective entries have different access classes, then
  the values for those attributes may differ and any
  combination of these values (and access classes) gives
  again a tuple in the relation.



       8/5/2011    Prof. Ehud Gudes Security Ch 7        105
    Polyinstantiation Integrity
Assume query: Dest = NY and Seats = 11 by C user –
need to add two rows over table from p. 105

Flight [Fl_Class]   Dest. [De_Class] Seats [Se_Class]      [Tuple_Class]

 CA909     [C]         H.K.   [C]             7      [C]       [C]

 AX301     [U]         K.L.   [U]             2      [U]       [U]

 GR555     [U]         L.A.   [C]             11     [C]       [C]

 GR555     [U]         L.A.   [C]             0      [U]       [C]

 GR555     [U]         N.Y.   [U]             11     [C]       [C]

 GR555     [U]         N.Y.   [U]             0      [U]       [U]


         8/5/2011        Prof. Ehud Gudes Security Ch 7              106
     Implementation Options
1. Rely only on ML-OS
    There is a separate single-level DBMS process running
       at each access class.
    Multi-level relations are stored as a collection of single-
       level operating systems.
    The DBMS has to use a partial ordering of access classes
       supported by the operating system.

2. DBMS is a Trusted Subject
    Proceed with the update and polyinstantiate the data, or
    Deny the update and record this event in an audit log.

         8/5/2011     Prof. Ehud Gudes Security Ch 7         107
   MLS Concurrecy Control
Assume user S locked a record for write and now user U
  tries to read it. The existence of this lock is already
  secret information!

If lock is at level S, user U (or U scheduler) should be
    unaware of it and will try to read the record.

If lock is at level U then user S violated BLP!

                  SOLUTION?         Read papers!



       8/5/2011     Prof. Ehud Gudes Security Ch 7          108
 Statistical DB Security
Statistical DB:  Contains information about individuals,
  but allows only aggregate queries (e.g., average age,
  rather than Joe‟s age).

New problem: It may be possible to infer some secret
  information!
      E.g., If I know Joe is the oldest sailor, I can ask “How
       many sailors are older than X?” for different values of X
       until I get the answer 1; this allows me to infer Joe‟s age.

Idea:   Insist that each query must involve at least N
  rows, for some N. Will this work? (No!)

       8/5/2011     Prof. Ehud Gudes Security Ch 7            109
 Why Minimum N is Not Enough
By asking “How many sailors older than X?” until the
  system rejects the query, can identify a set of N
  sailors, including Joe, that are older than X; let X=55
  at this point.

Next, ask “What is the sum of ages of sailors older
  than X?” Let result be S1.

Next, ask “What is sum of ages of sailors other than
  Joe who are older than X, plus my age?” Let result be
  S2.

S1-S2 is Joe‟s age!
    8/5/2011     Prof. Ehud Gudes Security Ch 7         110
  Types of Sensitive Data
Exact data – e.g. salary of John Doe
Bounds
Negative results – e.g. 0 is not the total number of
                     felonies

Existence – e.g. of AIDS virus
Probable values

      8/5/2011     Prof. Ehud Gudes Security Ch 7       111
  Example Database

 NAME         SEX        LEV             LOC             SAL      0.1   0.2   0.3
  (Not                (job level)    (Work location)   (Salary)
 stored)

DIAZ            M         60               SF             36      1     2     2

SMITH           F         58               SF             24      3     2     1

JONES           M         56               LA             26      4     2     3

KATZ            M         57               LA             30      3     3     2

CLARK           F         58               LA             28      5     1     4

WOND            F         60               LA             34      1     1     1

WEBB            M         58               SF             32      5     5     5




           8/5/2011            Prof. Ehud Gudes Security Ch 7                     112
 ‫‪Stat. DB security – size restriction‬‬
‫הגנה אפשרית מפני שתי שאילתות אלו היא הגבלה כי גודל התשובה לכל‬
                                       ‫שאילתא יהיה גדול מ-1!‬
                        ‫אולם אז ניתן לשאול את השאילתות הבאות:‬
                 ‫)‟‪Q1=COUNT(LOC=„SF‟LOC=„SF‬‬
          ‫)‟‪Q2=COUNT(LOC  =„SF‟SEX=„F‬‬
       ‫התשובה לשאילתא הראשונה תהיה 7 – מס' הרשומות בטבלה.‬
    ‫התשובה לשאילתא השנייה תהיה 6 וההפרש ביניהן אחד 1=2‪Q1-Q‬‬
                      ‫מכאן ניתן לבצע את שתי השאילתות הבאות:‬
             ‫)‪Q3=SUM(LOC=„SF‟LOC=„SF‟;SAL‬‬
            ‫)‪Q4=SUM(LOC=„SF‟SEX=„F‟;SAL‬‬
                       ‫והמשכורת הרצויה היא כמובן 3‪!Q4-Q‬‬
      ‫1102/5/8‬        ‫7 ‪Prof. Ehud Gudes Security Ch‬‬     ‫311‬
  ‫‪Stat. DB security – size restriction‬‬
  ‫בטבלה 5.7 רואים טבלה ובה מידע על עובדים ומשכורותיהם (שים לב ששדה‬
  ‫השם אינו מופיע בבסיס הנתונים). אחד הדברים שאיננו מעונינים לחשוף‬
‫הוא משכורתו של עובד מסוים. אולם קל מאוד כן לחשוף זאת ע"י שאילתא‬
       ‫חוקית לחלוטין (ע"י תהליך הסקה). שאילתא חוקית היא מהצורה:‬
                                     ‫)‪function (Predicate; Attribute‬‬
‫כאשר ‪ function‬היא פונקציה כמו ‪ COUNT‬או ‪ ,SUM‬ו-‪ Attribute‬הוא השדה‬
                                              ‫שעליו פועלת הפונקציה.‬
‫לדוגמא, נניח שאנו יודעים כי הפרט שאנו מעונינים בו ‪ Smith‬גרה בעיר ‪( SF‬סן‬
                                                ‫פרנסיסקו)והיא אשה.‬
                                            ‫אזי ביצוע השאילתות הבאות‬
                     ‫)‟‪COUNT (LOC=„SF‟ . SEX=„F‬‬
                  ‫)‪SUM (LOC=„SF‟ . SEX=„F‟;SAL‬‬                  ‫וכן‬
                                          ‫ייתן את משכורתה של ‪!Smith‬‬
       ‫1102/5/8‬         ‫7 ‪Prof. Ehud Gudes Security Ch‬‬             ‫411‬
  The individual Tracker
Assume C characterize the individual uniquely – then Q(C)
  or Q(C*S) is unanswerable, S is the searched field.

Assume C=AB where both Q(A) and Q(AB^) are
  answerable.

Then Q(C)=Q(A)-Q(AB^) or
     Q(C*S)=Q(A*S)-Q(AB^*S)




      8/5/2011     Prof. Ehud Gudes Security Ch 7      115
        The Individual Tracker - Example
Unique Identifier   Sex    Dept          Position       Salary ($K)   Political Contribution ($)
Adams                M     CS            Prof.            20               50
Baker                M     Math          Prof.            15               100
Cook                 F     Math          Prof.            25               200
Dodd                 F     CS            Prof.            15               50
Engel                M     Stat          Prof.            18               0
Flynn                F     Stat          Prof.            22               150
Grady                M     CS            Adm.             10               20
Hayes                M     Math          Prof.            18               500
Irons                F     CS            Stu.             3                10
Jones                M     Stat          Adm.             20               15
Knapp                F     Math          Prof.            25               100
Lord                 M     CS            Stu.             3                0


   C=F*CS*Prof, A=F, B=CS*Prof
                8/5/2011     Prof. Ehud Gudes Security Ch 7                             116
  The General Tracker
Assume threshold is K.
Find T such that
       2k <= count(T) <= n-2k

Then, k <= count(T+C) <= n-k and
      k <= count(T^+C) <= n-k

So, both are answerable!
And Q(C) = Q(T+C) + Q(T^+C) –n !


      8/5/2011   Prof. Ehud Gudes Security Ch 7   117
  Some Defenses
Replacing precise values with range values
Use samples from the original database
Perturb data randomly
Perturb results randomly
Partition the database
Audit trail and query analysis
      8/5/2011     Prof. Ehud Gudes Security Ch 7   118
  Security of Linear Queries
We consider queries of the form of eq. (3) applied to a
 database of N elements. All queries use the same value
 of k and the same weights aj.

We observe first that, knowing one weight aj and one data
 element x, we can compromise the entire database. Let
 q1 and q2 be the responses to the two queries:

      q1=q(z1, …, zj-1, x, zj+1, …, zk)
      q2=q(z1, …, zj-1, y, zj+1, …, zk)

  which differ only in their use of data elements x and y
  in the jth position.

      8/5/2011      Prof. Ehud Gudes Security Ch 7      119
  Security of Linear Queries, cont.
Equation (3) shows that
      (q1 – q2) = aj(x – y)

  which can be solved for y. Now the entire database is
  vulnerable: we pose q1 once and a new q2 for each of
  the N – 1 unknown data elements, effecting a full
  compromise with N queries and N – 1 applications of eq.
  (4). As soon as two data elements, x and y, are known,
  we can also use eq. (4) to solve for any un known
  weight.



       8/5/2011    Prof. Ehud Gudes Security Ch 7     120
  Security of Linear Queries, cont.
Example 3: Suppose that the runner‟s database
  implements the query
      q(z1, z2, z3) = 0.2z1+0.5z2 + 0.3z3

A user knows that the weight of the first key is 0.2 and
  that Smith‟s Max VOX is 68; thus the initial information
  is:
       a1 = 0.2
       x11 = 68



       8/5/2011    Prof. Ehud Gudes Security Ch 7        121
   Security of Linear Queries, cont.
To determine Jones‟s Max VOX, the user proceeds as
  follows. He poses the two queries q(x11, x12, x13), to
  which the system will respond, respectively,

      q1 = 407.6
      q2 = 406.2

Equation (4) can be used to solve for x21:
      x21 = x11 – (q1-q2)/a1
             = 68 – 1.4/0.2
             = 68 – 7
             = 61
  which is Smith‟s Max VOX.
       8/5/2011     Prof. Ehud Gudes Security Ch 7         122
          Runner’s Database
                        1               2              3           4               5               6                7
                                                       Prior 8 weeks
         Keys         Max          Train pace        Total       Longest        Fastest         Fastest         Year
     i          j     VOXa      (seconds/mile        miles         run          1 mile         10 miles        of birth
                                      )                                       (seconds)       (seconds)
1   Smith              68             380             680           22            260            3183           1948

2   Jones              61             405             530           18            287            3520           1950

3   Burns              56             440             460           20            316            3818           1940

4   Cohen              48             485             410           18            368            4447           1930

5   Cook               49             470             375           20            360            4394           1962

6   Bloom              54             440             430           20            328            3980           1948

7   King               53             440             405           20            334            4072           1943

8   Frank              72             370             705           23            251            2997           1947

         “Max VOX” is the maximum volume of oxygen processable in milliliters per kilogram body weight per minute

                    8/5/2011                Prof. Ehud Gudes Security Ch 7                                          123
         The Inference Problem –
Answering Queries Without Revealing Secrets


                                   “is Mediocrates an Athenian?”
                   yes             mum       no
                    k
                                    “is Mediocrates a Boeotian?”
                   yes             mum          no
                   k

                                                 “is Mediocrates a Corinthian?”

                              yes               mum
                                                            no
                               k
                                                                 “is Mediocrates a Dorian?”
                                          yes                mum            no
                                           k                               k
 K  „M is peaceable‟
       8/5/2011          Prof. Ehud Gudes Security Ch 7                                       124
   The Inference Problem, cont.
To show that a refusal to answer may reveal a secret, we
  now consider a system that only refuses if the answer
  would reveal a secret. Suppose the following integrity
  constraints apply to a database containing the fact that
  Mediocrates is an Athenian:

      Every man is an Athenian, a Boeotian, a Corinthian, or a Dorian;
      All Athenians and Corinthians are peaceable;
      All Boeotians and Dorians are violent;




       8/5/2011      Prof. Ehud Gudes Security Ch 7              125
  The Inference Problem, cont.
Mediocrates does not wish it to be known that he is
  peaceable. Rhinologus, a public nuisance, tries to find
  out about Mediocrates:

      Rhinologus:    Is Mediocrates an Athenian?
      System:        I will not tell you.
      Rhinologus:    Is he a Boeotian?
      System:        No.
      Rhinologus:    Is he a Corinthian?
      System:        No.
      Rhinologus:    Is he a Dorian, then?
      System:        I will not tell you.
       8/5/2011     Prof. Ehud Gudes Security Ch 7          126
                             Summary
 Three main security objectives: secrecy, integrity, availability.
 DB admin is responsible for overall security.
       Designs security policy, maintains an audit trail, or
        history of users‟ accesses to DB.

 Two main approaches to DBMS security: discretionary and mandatory
    access control.
     Discretionary control based on notion of privileges.
     Mandatory control based on notion of security
      classes.

   Statistical DBs try to protect individual data by supporting only
    aggregate queries, but often, individual information can be inferred.

           8/5/2011       Prof. Ehud Gudes Security Ch 7              127

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:14
posted:8/5/2011
language:English
pages:127