Chapter 4 -- Database Security PDF

Final Term Chapter 4: A Look at Security, Advance Modelling, and Distribution ON DATABASE SECURITY 4.1 AN INTRODUCTION TO DATABASE SECURITY ISSUES 4.1.1 Types of Security Database security is a broad area that addresses many issues including the following: ▪ Legal and ethical iss...

Final Term Chapter 4: A Look at Security, Advance Modelling, and Distribution ON DATABASE SECURITY 4.1 AN INTRODUCTION TO DATABASE SECURITY ISSUES 4.1.1 Types of Security Database security is a broad area that addresses many issues including the following: ▪ Legal and ethical issues regarding the right to access certain information. Some information may be deemed private and cannot be accessed legally by unauthorized persons. ▪ Policy issues at the government, institutional, or corporate level regarding what kinds of information should not be made publicly available – for example, credit ratings and personal medical records. ▪ System-related issues such as the system levels as which various security functions should be enforced— for example whether a security function should be handled at the physical hardware level, the operating system level or the DBMS level. ▪ The need in some organizations to identify multiple security levels and to categorize the data and users based on these classifications—for example, top secret, secret, confidential an unclassified. The security policy of the organization with respect to permitting access to various classifications of data must be enforced. Threats to Database. Threats to database result in the loss of degradation of some or all of the following commonly accepted security goals: integrity, availability, and confidentiality. ▪ Loss of Integrity. Database integrity refers to the requirement that information be protected from improper modification. Modification of data includes creation, insertion, changing the status of data, and deletion. Integrity is lost if unauthorized changes are made to the data by either intentional or accidental acts. If loss of data is not corrected, continued use of contaminated systems or corrupted data could result in inaccuracy, fraud, or erroneous decisions. ▪ Loss of Availability. Database availability refers to making object available to a human user or program to which they have a legitimate right. ▪ Loss of Confidentiality. Database confidentiality refers to the protection of data from unauthorized disclosure. The impact of unauthorized disclosure of confidential information can range from violation of the Data Privacy Act to the jeopardization of national security. Unauthorized unanticipated, or unintentional disclosure could result in loss of Public confidence, embarrassment, or legal action against the organization. To protect databases against these types of threats, it is common to implement four kinds of control measures: access control, inference control, flow control, and encryption. We discuss each of these in this chapter. In a multiuser database system, the DBMS must provide techniques to enable certain users or user groups to access selected portions of a database without gaining access to the rest of the database. This is particularly important when a large integrated database is to be used by many different users within the same organization. For example, sensitive information such as employee salaries or performance 'reviews should be kept confidential from most of the database system's users. A DBMS typically includes a database security and authorization subsystem that is responsible for ensuring the security of portions of a database against unauthorized access. It is now customary to refer to two types of database security mechanisms: ▪ Discretionary security mechanisms. These are used to grant privileges to users, including the capability to access specific data files, records, or fields in a specified mode (such as read, insert, delete, or update). ▪ Mandatory security mechanisms. These are used to enforce multilevel security by classifying the data and users into various security classes (or levels) and then implementing the appropriate security policy of the organization. For example, a  typical security policy is to permit users at a certain classification level to see only the data items classified at the user's own (or lower) classification level. An extension of this is role-based security, which enforces policies and privileges based on the concept of roles. 4.1.2 Control Measures There are four main control measures that are used to provide security of data in databases. They are as follows: ▪ Access control ▪ Inference control ▪ Flow control ▪ Data encryption A security problem common to computer systems is that of preventing unauthorized persons from accessing the system itself, either to obtain information or to make malicious changes in a portion of the database. The security mechanism of a DBMS must include provisions for restricting access to the database system as a whole. This function is called access control and is handled by creating user accounts and passwords to control the login process by the DBMS. We discuss access control techniques in Section 4.1.3. Statistical databases are used to provide statistical information or summaries of values based on various criteria. For example, a database for population statistics may provide statistics based on age groups, income levels, household size, education levels, and other criteria. Statistical database users such as government statisticians or market research firms are allowed to access the database to retrieve statistical information about a population but not to access detailed confidential information about specific individuals. Security for statistical databases must ensure that information about individuals cannot be accessed. It is sometimes possible to deduce or infer certain facts concerning individuals from queries that involve only summary statistics on groups; consequently, this must not be permitted either. This problem, called statistical database security, is discussed briefy in Section 4.4. The corresponding control measures are called inference control measures. Another security issue is that of flow control, which prevents information from flowing in such a way that it reaches unauthorized users. It is discussed in Section 4.5. Channels that are pathways for information to flow implicitly in ways that violate the security policy of an organization are called covert channels. We briefly dis. cuss some issues related to covert channels in Section 4.5.1. A final control measure is data encryption, which is used to protect sensitive data (such as credit card numbers) that is transmitted via some type of communications network. Encryption can be used to provide additional protection for sensitive portions of a database as well. The data is encoded using some coding algorithm. An unauthorized user who accesses encoded data will have difficulty deciphering it, but authorized users are given decoding or decrypting algorithms (or keys) to decipher the data. Encrypting techniques that are very difficult to decode without a key have been developed for military applications. Section 4.6 briefly discusses encryption techniques, including popular techniques such as public key encryption, which is heavily used to support Web based transactions against databases, and digital signatures, which are used in personal communications. A comprehensive discussion of security in computer systems and databases is outside the scope of this textbook. We give only a brief overview of database security techniques here. The interested reader can refer to several of the references discussed in the Selected Bibliography at the end of this chapter for a more comprehensive discussion. 4.1.3 Database Security and the Database Administrator (DBA) The database administrator (DBA) is the central authority for managing a database system. The DBA'S responsibilities include granting privileges to users who need to use the system and classifying users and data under the policy of the organization. The DBA has a DBA account in the DBMS, sometimes called a system or superuser account, which provides powerful capabilities that are not made available to regular database accounts and users. DBA-privileged commands include commands for granting and revoking privileges to individual accounts, users, or user groups and for performing the following types of actions: 1. Account creation. This action creates a new account and password for a user or a group of users to enable access to the DBMS. 2. Privilege granting. This action permits the DBA to grant certain privileges to certain accounts 3. Privilege revocation. This action permits the DBA to revoke (cancel) certain privileges that were previously given to certain accounts. 4 Security level assignment. This action consists of assigning user accounts to the appropriate security classification level. The DBA is responsible for the overall security of the database system. Action 1 in the preceding list is used to control access to the DBMS as a whole, whereas actions 2 and 3 are used to control discretionary database authorization, and action 4 is used to control mandatory authorization. 4.1.4 Access Protection, User Accounts, and Database Audits Whenever a person or a group of persons needs to access a database system, the individual or group must first apply for a user account. The DBA will then create a new account number and password for the user if there is a legitimate need to access the database. The user must log in to the DBMS by entering the account number and password whenever database access is needed. The DBMS checks that the account number and password are valid; if they are, the user is permitted to use the DBMS and access the database. Application programs can also be considered users and can be required to supply passwords. It is straightforward to keep track of database users and their accounts and passwords by creating an encrypted table or file with two fields: AccountNumber and Password. This table can easily be maintained by the DBMS. Whenever a new account is created, a new record is inserted into the table. When an account is canceled, the corresponding record must be deleted from the table. The database system must also keep track of all operations on the database that are applied by a certain user throughout each login session, which consists of the sequence of database interactions that a user performs from the time of logging in to the time of logging off. When a user logs in, the DBMS can record the user's account number and associate it with the terminal from which the user logged in. All operations applied from that terminal are attributed to the user's account until the user logs off. It is particularly important to keep track of update operations that are applied to the database so that, if the database is tampered with, the DBA can determine which user did the tampering. To keep a record of all updates applied to the database and of particular users who applied each update, we can modify the system log. The system log includes an entry for each operation applied to the database that may be required for recovery from a transaction failure or system crash. We can expand the log entries so that they also include the account number of the user and the online terminal ID that is applied to each operation recorded in the log. If any tampering with the database is suspected, a database audit is performed, which consists of reviewing the log to examine all accesses and operations applied to the database during a certain period. When an illegal or unauthorized operation is found, the DBA can determine the account number used to perform the operation. Database audits are particularly important for sensitive databases that are updated by many transactions and users, such as a banking database that is updated by many bank tellers. A database log that is used mainly for security purposes is sometimes called an audit trail. 4.2 DISCRETIONARY ACCES CONTROL BASED ON GRANTING AND REVOKING PRIVILEGES The typical method of enforcing discretionary access control in a database system is based on the granting and revoking of privileges. Let us consider privileges in the context of a relational DBMS. In particular, we will discuss a system of privileges somewhat similar to the one originally developed for the SQL language (see Chapter 8). Many current relational DBMSs use some variation of this technique The main idea is to include statements in the query language that allow the DBA and selected users to grant and revoke privileges. 4.2.1 Types of Discretionary Privileges In SQL2, the concept of an authorization identifier is used to refer, and roughly speaking to a user account (or group of user accounts) For simplicity, we will use the words user or account interchangeably in place of authorization identifier. The DBMS must provide selective access to each relation in the database based on specific accounts. Operations may also be controlled, thus, having an account does not necessarily entitle the account holder to all the functionality provided by the DBMS Informally, there are two levels for assigning privileges to use the database system: ▪ The account level. At this level, the DBA specifies the particular privileges that each account holds independently of the relations in the database. ▪ The relation (or table) level. At this level, the DBA can control the privilege to access each individual relation or view in the database. The privileges at the account level apply to the capabilities provided to the account itself and can include the CREATE SCHEMA or CREATE TABLE privilege, to create a schema or base relation; the CREATE VIEW privilege; the ALTER privilege, to apply schema changes such as adding or removing attributes from relations; the DROP privilege, to delete relations or views; the MODIFY privilege, to insert, delete, or update tuples; and the SELECT privilege, to retrieve information from the database by using a SELECT query. Notice that these account privileges apply to the account in general. If a certain account does not have the CREATE TABLE privilege, no relations can be created from that account. Account-level privileges are not defined as part of SQL2; they are left to the DBMS implementers to define. In earlier versions of SQL, a CREATETAB privilege existed to give an account the privilege to create tables (relations). The second level of privileges applies to the relation level, whether they are base relations or virtual (view) relations. These privileges are defined for SQL2. In the following discussion, the term relation may refer either to a base relation or to a view, unless we explicitly specify one or the other. Privileges at the relation level specify for each user the individual relations on which each type of command can be applied. Some privileges also refer to individual columns (attributes) JO relations. SQL2 commands provide privileges at the relation and attribute level only. Although this is quite general, it makes it difficult to create accounts with limited privileges. The granting and revoking of privileges generally follow an authorization model for discretionary privileges known as the access matrix model, where the rows of a matrix M represent subjects (users, accounts, programs) and the columns represent objects (relations, records, columns, views, operations). Each position M(i, j) in the matrix represents the types of privileges (read, write, update) that subject 1 holds on object j. To control the granting and revoking of relation privileges, each relation R in a database is assigned an owner account which is typically the account that was used when the relation was created in the first place. The owner of a relation is given all privileges in that relation. In SOL2, the DBA can assign an owner to a whole schema by creating the schema and associating the appropriate authorization identifier with that schema, using the CREATE SCHEMA command (see Section 8.1.1). The owner account holder can pass privileges on any of the owned relations to other users by granting privileges to their accounts. In SQL the following types of privi- leges can be granted on each individual relation R: ▪ select (retrieval or read) privilege on R. Gives the account retrieval privilege. This gives the account privilege to use the SELECT statement to retrieve tuples from R. ▪ modify privilege on R. This give the account the capability to modify tuples of R. in SQL this  privilege is further divided into UPDATE, DELETE and INSERT privilege to apply corresponding SQL command to R. Additionally, both the INSERT and UPDATE privilege can specify that the only certain attributes of R can be updated by the account. ▪ Reference privilege on R. this gives the account the capability to reference relation R when specifying integrity constraints. This privilege can also be restricted to specific attributes of R. 4.2.2 Specifying Privileges Using Views The mechanism of views is an important discretionary authorization mechanism in its own right. For example, if the owner A of a relation R wants another account B to be able to retrieve only in some fields of R, then A can create a view of V of R that includes only those attributes and then grant SELECT on V to B. The same applies the limiting B to retrieving only certain tuples of R; a view V’ can created by defining the view by means of a query that selects only those tuples from R that A wants to allow B to access. We will illustrate this discussion with the example given in Section 23.2.5. 23.2.3 Revoking Privileges In some cases, it is desirable to grant a privilege to a user temporarily. For example, the owner of a relation may want to grant the SELECT privilege to a user for a specific task and then revoke that privilege once the task is completed. Hence, A mechanism for revoking privileges is needed. In SQL a REVOKE command is included for the purpose of canceling privileges. We will see how the REVOKE command is used in the example of 4.2.5. 4.2.4 Propagation of Privileges Using the GRANT OPTION Whenever owner A of a relation R grants a privilege on R to another account B, the privilege can be given to B with or without the GRANT OPTION. If the GRANT OPTION is given, this means that B can also grant that privilege on R to other accounts. Suppose that B is given the GRANT OPTION by A and that B then grants the privilege on R to a third account C also with GRANT OPTION. In this Way privileges on R can propagate to other accounts without the knowledge of the owner of R. If the owner account A now revokes the privilege granted to B, all the privileges that B propagated based on that privilege should automatically be revoked by the system. It is possible for a user to receive a certain privilege from two or more sources. For example, A4 may receive a certain UPDATE R privilege from both A2 and A3. In such a case, if A2 revokes this privilege from A4, A4 will still continue to have the privilege by virtue of having been granted it from A3. If A3 later revokes the privilege from A4, A4 totally loses the privilege, Hence, a DBMS that allows propagation of privileges must keep track of how all the privileges were granted so that revoking of privileges can be done correctly and completely. 4.2.5 An Example Suppose that the DBA creates four accounts- A1, A2, A3, and A4-and wants only 41 to be able to create base relations; then the DBA must issue the following GRANT command in SQL: GRANT CREATETAB TO A1; The CREATETAB (create table) privilege gives account A1 the capability to create new database tables (base relations) and is hence an account privilege. This privilege was part of earlier versions of SQL but is now left to each individual system implementation to define. In SQL2 the same effect can be accomplished by having the DBA issue a CREATE SCHEMA command, as follows: CREATE SCHEMA EXAMPLE AUTHORIZATION A1. Now user account A1 can create tables under the schema called EXAMPLE. To continue our example, suppose that A1 creates the two base relations EMPLOYEE and DEPARTMENT shown in Figure Figure 4. l; Al is then the owner of these two relations and hence has all the relation privileges on each of them. Next, suppose that account A1 wants to grant to account A2 the privilege to insert and delete tuples in both of these relations. However, A1 does not want A2 to be able to propagate these privileges to additional accounts. A1 can issue the following command: GRANT INSERT, DELETE ON EMPLOYEE, DEPARTMENT TO A2; EMPLOYEE Name Ssn Bdate Address Sex Salary Dno DEPARTMENT Dnumber Dname Mgr_ss Figure 4.1 Schemas for the two relations n EMPLOYEE and DEPARTMENT Notice that the owner account A1 of a relation automatically has the GRANT OPTION, allowing it to grant privileges on the relation to other accounts. However, account A2 cannot grant INSERT and DELETE privileges on the EMPLOYEE and DEPARTMENT tables because A2 was not given the GRANT OPTION in the preceding command. Next, suppose that A1 wants to allow account A3 to retrieve information from either of the two tables and also to be able to propagate the SELECT privilege to other accounts. A1 can issue the following command: GRANT SELECT ON EMPLOYEE, DEPARTMENT TO A3 WITH GRANT OPTION; The clause WITH GRANT OPTION means that A3 can now propagate the privilege to other accounts by using GRANT. For example, A3 can grant the SELECT privilege on the EMPLOYEE relation to A4 by issuing the following command: GRANT SELECT ON EMPLOYEE TO A4; Notice that A4 cannot propagate the SELECT privilege to other accounts because the GRANT OPTION was not given to A4. Now suppose that A1 decides to revoke the SELECT privilege on the EMPLOYEE relation from A3; A1 then can issue this command: REVOKE SELECT ON EMPLOYEE FROM A3; The DBMS must now automatically revoke the SELECT privilege on EMPLOYEE from A4, too, because A3 granted that privilege to A4 and A3 does not have the privilege anymore. Next, suppose that A1 wants to give back to A3 a limited capability to SELECT from the EMPLOYEE relation and wants to allow A3 to be able to propagate the privilege. The limitation is to retrieve only the Name, Bdate, and Address attributes and only for the tuples with Dno = 5. A1 then can create the following view: CREATE VIEW A3EMPLOYEE AS SELECT Name, Bdate, Address FROM EMPLOYEE SELECT WHERE Dno - 5; After the view is created, A1 can grant SELECT on the view A3EMPLOYEE to A3  as follows: GRANT SELECT ON EMPLOYEE TO A3 WITH GRANT OPTION; Finally, suppose that A1 wants to allow A4 to update only the Salary attribute of EMPLOYEE; A1 can then issue the following command: GRANT UPDATE ON EMPLOYEE (Salary) TO A4; The UPDATE or INSERT privilege can specify particular attributes that may be updated or inserted in a relation. Other privileges (SELECT, DELETE) are not attribute specific, because this specificity can easily be controlled by creating the appropriate views that include only the desired attributes and granting the corresponding privileges on the views. However, because updating views is not always possible, the UPDATE and INSERT privileges are given the option to specify particular attributes of a base relation that may be updated 4.2.6 Specifying Limits on Propagation of Privileges Techniques to limit the propagation of privileges have been developed, although they have not yet been implemented in most DBMSs and are not a part of SQL. Limiting horizontal propagation to an integer number i means that an account B given the GRANT OPTION can grant the privilege to at most i other accounts. Vertical propagation is more complicated; it limits the depth of the granting of privileges. Granting a privilege with a vertical propagation of zero is equivalent to granting the privilege with no GRANT OPTION. If account A grants a privilege to account B with the vertical propagation set to an integer number j > 0, this means that account B has the GRANT OPTION on that privilege, but B can grant the privilege to other accounts only with a vertical propagation less than j. In effect, vertical propagation limits the sequence of GRANT OPTIONS that can be given from one account to the next based on a single original grant of the privilege. We briefly illustrate horizontal and vertical propagation limits-- which are not available currently in SQL or other relational systems-- with an example. Suppose that Al grants SELECT to A2 on the EMPLOYEE relation with horizontal propagation equal to 1 and vertical propagation equal to 2. A2 can then grant SELECT to at most one account because the horizontal propagation limitation is set to 1. Additionally, A2 cannot grant the privilege to another account except with vertical propagation set to 0 (no GRANT OPTION) or 1; this is because A2 must reduce the vertical propagation by at least 1 when passing the privilege to others. As this example shows, horizontal and vertical propagation techniques are designed to limit the depth of propagation of privileges. 4.3 On Mandatory Access Control and Role-Based Access Control for Multilevel Security The discretionary access control technique of granting and revoking privilege on relations has traditionally been the main security mechanism for relational database systems. This is an all-or-nothing method: a user either has or does not have a certain privilege. In many applications, an additional security policy is needed that classifies data and users based on security classes. This approach, known as mandatory access control, would typically be combined with the discretionary access control mechanisms described in Section 4.2. It is important to note that most commercial DBMSs currently provide mechanisms only for discretionary access control. However, the need for multilevel security exists in government, military, and intelligence applications, as well as in many industrial and corporate applications. Typical security classes are top secret (TS), secret ($), confidential (C), and unclassified (U), where TS is the highest level and U is the lowest. Other more complex security classification schemes exist, in which the security classes are organized in a lattice. For simplicity, we will use the system with four security classification levels, where TS ≥ S ≥ C ≥ U, to illustrate our discussion. The commonly used model for multilevel security, known as the Bell-LaPadula model, classifies each subject (user, account program) and object (relation, tuple, column, view, operation) into one of the security classifications TS, S, C, or U. We will refer to the clearance (classification) of a subject S as class(S) and the classification of an object 0 as class(0). Two restrictions are enforced on data access based on the subject/object classifications: 1. A subject S is not allowed read access to an object O unless class(S) ≥ class(O). This is known as the simple security property. 2. A subject S is not allowed to write an object O unless class (S) ≤ class(O). This is known as the star property (or *-property). The first restriction is intuitive and enforces the obvious rule that no subject can read an object whose security classification is higher than the subject's security clearance. The second restriction is less intuitive. It prohibits a subject from writing an object at a lower security classification than the subject's security clearance. Violation of this rule would allow information to flow from higher to lower classifications, which violates a basic tenet of multilevel security. For example, a user (subject) with TS clearance may make a copy of an object with classification TS and then write it back as a new object with classification U, thus making it visible throughout the system. To incorporate multilevel security notions into the relational database model, it is common to consider attribute values and tuples as data objects. Hence, each attribute A is associated with a classification attribute C in the schema, and each attribute value in a tuple is associated with a corresponding security classification. In addition, in some models, a tuple classification attribute TC is added to the relation attributes to provide a classification for each tuple as a whole. Hence, a multilevel relation schema R with n attributes would be represented as R(A1, C1 ,A2 C2,... , An Cn, TC) where each Ci, represents the classification attribute associated with attribute Ai,. The value of the TC attribute in each tuple t- which is the highest of all attribute classification values within t _ provides a general classification for the tuple itself, whereas each Ci , provides a finer security classification for each attribute value within the tuple. The apparent key of a multilevel relation is the set of attributes that would have formed the primary key in a regular (single-level) relation. A multilevel relation will appear to contain different data to subjects (users) with different clearance levels. In some cases, it is possible to store a single tuple in the relation at a higher classification level and produce the corresponding tuples at a lower-level classification through a process known as filtering. In other cases, it is necessary to store two or more tuples at different classification levels with the same value for the apparent key. This leads to the concept of polyinstantiation, where several tuples can have the same apparent key value but have different attribute values for users at different classification levels. Figure 4.2. A multilevel relation to illustrate multilevel security. (a) the original EMPLOYEE tuples. (b) Appearance of EMPLOYEE after  filtering for classifications C users. (c) Appearance of EMPLOYEE after filtering for classification U users. (d) Polyinstantiation of the Smith tuple. We illustrate these concepts with the simple example of a multilevel relation shown in Figure 4.2(a), where we display the classification attribute values next to each attribute's value. Assume that the Name attribute is the apparent key, and consider the query SELECT * FROM EMPLOYEE. A user with security clearance S would see the same relation shown in Figure 4.2(a) since all tuple classifications are less than or equal to S. However, a user with security clearance C would not be allowed to see values for Salary of Brown' and Job_performance of Smith, since they have higher classification. The tuples would be filtered to appear as shown in Figure 4.2(b), with Salary and Job_performance appearing as null. For a user with security clearance U, the filtering allows only the Name attribute of Smith' to appear, with all the other attributes appearing as null (Figure 4.2(c)). Thus, filtering introduces null values for attribute values whose security classification is higher than the user's security clearance. In general, the entity integrity rule for multilevel relations states that all attributes that are members of the apparent key must not be null and must have the same security classification within each tuple. Additionally, all other attribute values in the tuple must have a security classification greater than or equal to that of the apparent key. This constraint ensures that a user can see the key if the user is permitted to see any part of the tuple. Other integrity rules, called null integrity and interinstance integrity, informally ensure that if a tuple value at some security level can be filtered (derived) from a higher-classified tuple, then it is sufficient to store the higher-classified tuple in the multilevel relation. To illustrate polyinstantiation further, suppose that a user with security clearance C tries to update the value of Job_performance of Smith' in Figure 23.2 to Excellent'; this corresponds to the following SQL update being issued: UPDATE EMPLOYEE SET Job_performance = ‘Excellent’ WHERE Name= ‘Smith’; Since the view provided to users with security clearance C (see Figure 4.2(b)) permits such an update, the system should not reject it;, otherwise, the user could infer that some nonnull value exists for the Job_performance attribute of Smith' rather than the null value that appears. This is an example of inferring information through what is known as a covert channel, which should not be permitted in highly secure systems (see Section 4.5.1). However, the user should not be allowed to overwrite the existing value of Job_performance at the higher classification level. The solution is to create a polyinstantiation for the 'Smith' tuple at the lower classification level C, as shown in Figure 4.2(d). This is necessary since the new tuple cannot be filtered from the existing tuple at classification S. The basic update operations of the relational model (INSERT, DELETE, UPDATE) must be modified to handle this and similar situations, but this aspect of the problem is outside the scope of our presentation. We refer the interested reader to the Selected Bibliography at the end of this chapter for further details. 4.3.1 Comparing Discretionary Access Control and Mandatory Access Control Discretionary Access Control (DAC) policies are characterized by a high degree of (flexibility, which makes them suitable for a large variety of application domains. The main drawback of DAC models is their vulnerability to malicious attacks, such as Trojan horses embedded in application programs. The reason is that discretionary authorization models do not impose any control on how information is propagated and used once it has been accessed by users authorized to do so. By contrast, mandatory policies ensure a high degree of protection-- in a way, they prevent any illegal flow of information. Therefore, they are suitable for military types of applications, which require a high degree of protection. However, mandatory policies have the drawback of being too rigid in that they require a strict classification of subjects and objects into security levels, and therefore they are applicable to very few environments. In many practical situations, discretionary policies are preferred because they offer a better trade-off between security and applicability. 4.3.2 Role-Based Access Control Role-based access control (RBAC) emerged rapidly in the 1990s as a proven technology for managing and enforcing security in large-scale enterprise-wide systems. Its basic notion is that permissions are associated with roles, and users are assigned to appropriate roles. Roles can be created using the CREATE ROLE and DESTROY ROLE commands. The GRANT and REVOKE commands discussed under DAC can then be used to assign and revoke privileges from roles. RBAC appears to be a viable alternative to traditional discretionary and mandatory access controls; it ensures that only authorized users are given access to certain data or resources. Users create sessions during which they may activate a subset of roles to which they belong. Each session can be assigned to many roles but it maps to one user or a single subject only. Many DBMSs have allowed the concept of roles, where privileges can be assigned to roles. Role hierarchy in RBAC is a natural way to organize roles to reflect the organization's lines of authority and responsibility. By convention, junior roles at the bottom are connected to progressively senior roles as one moves up the hierarchy. The hierarchic diagrams are partial orders, so they are reflexive, transitive, and anti-symmetric. Another important consideration in the RBAC system is the possible temporal constraints that may exist on roles, such as time and duration of roles activations, and the timed triggering of a role by an activation of another role. Using an RBAC model is a highly desirable goal for addressing the key security requirements of Web-based applications. Roles can be assigned to workflow tasks so that a user with any of the roles related to a task may be authorized to execute it and may play a certain role for a certain duration only. RBAC models have several desirable features, such as flexibility, policy neutrality, better support for security management and administration, and other aspects that make them attractive candidates for developing secure Web-based applications. In contrast, DAC and mandatory access control (MAC) models lack the capabilities needed to support the security requirements of emerging enterprises and Web-based applications. In addition, RBAC models can represent traditional DAC and MAC policies as well as user-defined or organization-specific policies. Thus, RBAC becomes a superset model that can in turn, mimic the behavior of DAC and MAC systems. Furthermore, an RBAC model provides a natural mechanism for addressing the security issues related to the execution of tasks and workflows. Easier deployment over the Internet has been another reason for the success of RBAC models.