We want to implement an access control system that would provide the enterprise with both the benefits of Discretionary Access Control (DAC), and of Mandatory Access Control (MAC). We recall from the lecture that DAC provides flexibility and convenience in allowing users participation in the process of access control. On the other hand, MAC provides the enterprise with the protection of sensitive content. But MAC introduces a rough classification of users and data. We would like to be able to be much more flexible in making the data available to authorized users and at the same time making data not available to users for whom the access to data is not necessary. To simplify matters, we will accept granularity of access to tables.
Since there is no ``free lunch'', we need an additional authority that will be able to forbid the access to tables by ordinary users. This is the Security Officer (SO) . In reality this may be more than one person that decides which data is not appropriate for a specific user. In short SO may declare that a specific table should not be accessed by a given user. To do this, the SO must be able to declare a table inaccessible to a give user. For instance, the SO may decide that the user marek should not access the table design. Thus SO needs to have a place there she will be able to declare that the access of marek the table design can not happen. Thus, if marek will attempt to access the table design then the access should be denied, and this attempt should be logged in the table of unauthorized attempts.
Now, let us assume that the user dexter attempts to give marek access to the table design . Clearly, such attempt should fail (because the record Mmarek, design> is in the taable forbidden and dexter should be informed that she attempted to give marek access to the data marek is not authorized to access, and SO should be informed about this event (because it may be a sign of a case of Trojan Horse attack, as discussed in slides.)
Of course if there is no information that marek can not access the table design then the access to design should be given to marek providing dexter had the access right to the table design with grant option.
To realize the above model, this project builds two system tables (not just one) One is that of assigned privileges (called assigned) and the other one is the table of forbidden privileges, called forbidden. A quick analysis of the above description tells us that the table forbidden can be accessed only by SO, and not by ordinary users.
As mentioned above, he granularity of the privileges will be on the level of tables (i.e. we control the access to the entire table). Moreover, to simplify things a bit, instead of usual privileges (read, write, update, etc) we will have just one. Think about it as we give all of these privileges, or none at all. A user U may grant further privileges on a table T to user U' (i.e. the table assigned is inserted the record (U',T, B)) where B is a Boolean, if:
When a user U issues a command `grant A to U' when the record (U',T) is in forbidden then U will receive an error message `grant of access to T by U' unacceptable' and SO receives a message that U attempted to provide an access to U' to a restricted table. The lists must be mutually consistent, that is, one can not have a permission for the user (say) marek to access the table employees in the list assigned and at the same time a record forbidding such access on the table forbidden. The table forbidden can be modified only by SO.
Last updated: February 8, 2018