Basic Concept of Multilevel Database Security - Multilevel Security for Relational Databases - page 21

Table 2.3 Employee Relation in MLS Form

EMPLOYEE DEPARTMENT SALARY

Ahmed U Accounting U Null U

Table 2.4 S User View for Employee Relation
after Updating the Salary to 10,000 by S User
EMPLOYEE DEPARTMENT SALARY

Ahmed U Accounting U 10,000 S

Table 2.5 U User View for Employee Relation
after Updating the Salary to 7,000 by U User
EMPLOYEE DEPARTMENT SALARY

Ahmed U Accounting U 7,000 U

Table 2.6 S User View for Employee Relation
after Updating the Salary to 7,000 by U User

EMPLOYEE DEPARTMENT SALARY

Ahmed U Accounting U 7,000 U

Ahmed U Accounting U 10,000 S

• Next, a U user updates the salary to be 7,000. The modification
cannot be rejected because this leads to the covert channel
problem.
• Thus, there are two options left: The first option is that the
salary attribute can be overwritten in place at the cost of
destroying secret data. This results in breaking the data integ-
rity, as shown in Table 2.5. The second option is the invisible
polyinstantiation, which will modify the relation in Table 2.4
to the relations in Table 2.6.

2.3.2 Visible Polyinstantiation

The visible polyinstantiation (polyhigh) can occur when a user at a
high level of security needs to insert a new tuple that contains the
same primary key as in an existing tuple with a low security level [20].