The query rewriting procedure as illustrated in previous sections is implemented by Algorithm 3. For simplicity, we only consider queries without any subquery. However, note that queries containing subqueries can be processed by Algorithm 3 by applying the procedure first to the inner queries, and then to the outer query. Without loss of generality, to keep the notation simple, Algorithm 3 considers only authorizations for the SELECT privilege.
Algorithm 3 receives as input the submitted query q, the set of access control policies which applies to the requestor user u (i.e., SysAuthu), the set of non-harmful data
dependencies DD, the correlation hypergraph GS and the corresponding GS(u).
As a first step, Algorithm computes the set requestedAttributesq (Line 2). Then,
Algorithm 3 verifies which of the attributes in this set are authorized to u. In doing this, it checks which attributes in requestedAttributesq belong to a relation specified in the
FROM clause Fq that is authorized to u, and stores them in authorizedAttributesq (Line
3).
Then, attributes in authorizedAttributesq are removed from requestedAttributesq
(Line 4) so as to leave in requestedAttributesqonly those attributes that are not explic-
itly authorized. Afterwards, the WHERE clause is stored into a temporary variable (Line 5). Then, for each queried table T (i.e., for each table contained in the FROM clause) the procedure detects all the access control policies whose object is T (Line 6). In case access to table T is not explicitly authorized by any access control policy (Line 7), the procedure computes the intersection between requestedAttributesq and the set of attributes of the
table schema, to detect any possible implicitly authorizable attribute for T . These at- tributes, if any, are stored into a variable denoted as unauthorizedAttributesq (Line 8).
Then, Algorithm 3 verifies which attributes in unauthorizedAttributesq are implicitly
authorizable for u. Thus, for each attribute a in unauthorizedAttributesq, Algorithm 3
computes the subset of data dependencies having a in the right part of the implication (Line 10). If no data dependency implying a is available, the algorithm returns an error message (Line 32).
If at least one dependency dd is found, Algorithm 3 starts an iteration over all the detected dependencies (Line 12). As mentioned above, the determinant of the depen- dency must be explicitly authorized to u, that is, there must exist an access control policy acp whose object is the table containing the data dependency determinant. All the eligible policies are stored into a variable named P oliciesF orDeterminant (Line 13). Whether no acp in SysAuthu authorizes the dependency determinant, the dependency
is discarded and removed from dependenciesF orAttribute (Line 15).
Once all suitable dependencies have been considered, the set dependenciesF orAttributes contains the dependencies that implicitly make a authorizable. In case there is no data
4.5 Security Analysis 91
dependency in the set dependenciesF orAttributes, the algorithm returns an error mes- sage (Line 29). Otherwise, in case that dependenciesF orAttributes is not empty, under the assumption that there exists only one dependency that determine the iterated at- tribute a, the procedure denotes as dd? the dependency contained in the set (Line 19). All the access control policies authorizing u to access the attributes in dd?.Det are col-
lected in policiesF orDeterminant (Line 20). The set policiesF orDeterminant is then passed to a function, denoted as combinePolicies. In case policiesF orDeterminant contains only one access control policy acp, the function returns the policy itself; as such, acp? ≡acp (Line 21). In case more than one access control policy grants u, the access over attributes in dd.Det, combinePolicies returns a temporary access control policy acp? defined such that acp?.sub = u, acp?.priv = SELECT, and acp?.obj = V?, where V? is a temporary view defined as the union of the projection of the attributes in dd.Det from all the acp.obj. More formally,
V? = [
∀acp∈policiesF orDeterminant
πdd.Det(acp.obj).
Here we adopt the algebraic operator πA(T ) to denote the projection of a set of attributes
A out of a table T . Once Algorithm 3 has selected both the dependency and the access control policy, it computes the view V(dd?,acp?) (see Section 4.2). Then, Algorithm 3
generates additional conditions that have to be appended in AND to the original WHERE clause, if any (Line 23).
Once all the additional constraints have been computed and appended to Wqrw,
authorizedAttributesqis computed again, considering the attributes added by the rewrit-
ing procedure as well (Line 38). Afterwards, Algorithm 3 performs a correlation control, as described in Definition 4.3.3 (Lines 39-43). If the control fails, Algorithm 3 returns an error message. Otherwise, the input query is rewritten by replacing the previously WHERE clause with the newly computed Wqrw (Line 48). Finally, qrw is executed over
the database.
4.5 Security Analysis
In this section, we illustrate the correctness and the completeness properties of Algorithm 3. According to [68], correctness ensures that for each tuple returned by qrw it exists an access control policy authorizing the requestor user to gain access to it. In contrast, the completeness property ensures that each tuple returned by the original query and authorized to the requestor is also included in the result set of qrw.
However, supporting implicit authorizable attributes requires to revise the traditional properties definition introduced in [68]. Moreover, it is relevant to note that, since the proposed rewriting strategy composes the rewritten query by processing at attribute level (i.e., explicitly authorized attribute and implicitly authorized attribute), the correctness
property has to be proved at attribute level. Thus, for the correctness property we have to show that for each tuple t returned by qrw there exists either an access control policy authorizing the requestor user to gain access to, or there exists a non-harmful data dependency and an access control policy that makes each attribute in t implicitly authorizable.
Theorem 4.5.1 (Correctness.) Let q be the query submitted by user u, let qrw be the rewritten query returned by Algorithm 3. Let Rs(q) and Rs(qrw) denote the result set returned by q and qrw, respectively. Let DD be the set of non-harmful data depen- dencies defined in the system. For each tuple t ∈ Rs(qrw) and for each attribute a ∈ schema(Rs(qrw)):
∃acp ∈ SysAuthu, such that
a ∈ schema(acp.obj) ∧ t[a] ∈ πa(acp.obj)5
(P.1) or
∃dd? ∈ DD ∧ ∃acp? ∈ SysAuthu, such that dd?.Det ⊆ schema(acp?.obj) ∧
∧ t[a] ∈ πa(V(dd?,acp?.obj)).
(P.2)
The formal proof of Theorem 4.5.1 is provided in Appendix A.
Similarly to correctness, also completeness definition has to be revised to consider the implicitly authorization concept.
Theorem 4.5.2 (Completeness). Let q be the query submitted by user u, let qrw be the rewritten query returned by Algorithm 3, where Rs(q) and Rs(qrw) denote the
result set returned by q and qrw, respectively. Let DD be the set of non-harmful data dependencies defined in the system. For each tuple t ∈ Rs(qrw) and for each attribute a ∈ schema(Rs(qrw)) such that:
∃acp ∈ SysAuthu, such that
a ∈ schema(acp.obj) ∧ t[a] ∈ πa(acp.obj)
(P.1) or
∃dd? ∈ DD ∧ ∃acp? ∈ SysAuthu, such that dd?.Det ⊆ schema(acp?.obj) ∧
∧ t[a] ∈ πa(V(dd?,acp?.obj))
(P.2)
then t ∈ Rs(qrw).
Appendix B provides the formal proof of Theorem 4.5.2.
5