An extended access control mechanism exploiting data dependencies

Abstract

In general, access control mechanisms in DBMSs ensure that users access only those portions of data for which they have authorizations, according to a predefined set of access control policies. However, it has been shown that access control mechanisms might be not enough. A clear example is the inference problem due to functional dependencies, which might allow a user to discover unauthorized data by exploiting authorized data. In this paper, we wish to investigate data dependencies (e.g., functional dependencies, foreign key constraints, and knowledge-based implications) from a different perspective. In particular, the aim was to investigate data dependencies as a mean for increasing the DBMS utility, that is, the number of queries that can be safely answered, rather than as channels for releasing sensitive data. We believe that, under given circumstances, this unauthorized release may give more benefits than issues. As such, we present a query rewriting technique capable of extending defined access control policies by exploiting data dependencies, in order to authorize unauthorized but inferable data.

This is a preview of subscription content, log in to check access.

Fig. 1
Fig. 2
Fig. 3
Fig. 4

Notes

  1. 1.

    We assume that access control policies are stored into a unique authorization catalog, denoted as SysAuth, whereas we denote with \(\mathtt{SysAuth}_{u} \) all the access control policies that apply to a user u, i.e., \(\mathtt{SysAuth}_{u}\) = \(\{\mathtt{acp} \in \mathtt{SysAuth}\ |\ id_{u} \in \mathtt{acp.sbj} \}\), where \(id_{u}\) denotes the id of user u. Moreover, we use dot notation to specify the components of a tuple, that is, we denote as acp.sbj, acp.obj, and acp.priv, respectively, the subject, the object, and the privilege of a given access control policy acp.

  2. 2.

    More sophisticated approaches could be investigated as well, aiming at automatically identifying the non-harmful dependencies. This could be reached, as an example, by exploiting security labels describing the data sensitiveness, as done in the mandatory access control model.

    Fig. 1
    figure1

    DBMS reference architecture

  3. 3.

    A section hypergraph of an hypergraph \(G = (N,E)\) is defined as an hypergraph \(G'=(N',E')\) such that \(N'\subseteq N\) and \(E' = \{e'\ |\ e' \subseteq N'\}\).

  4. 4.

    Thereafter, we use dot notation to distinguish components of \(G_\mathbf{S}\) and \(G_\mathbf{S}(u)\). As an example, \(G_\mathbf{S}.E\) and \(G_\mathbf{S}(u).E\) denote the set of hyperedges of, respectively, the correlation hypergraph and the user correlation hypergraph.

  5. 5.

    We denote as t[a] the value of attribute a in the tuple t.

  6. 6.

    Facebook Query Language: https://developers.facebook.com/docs/reference/fql.

References

  1. 1.

    Bender, G., Kot, L., Gehrke, J.: Explainable security for relational databases. In: Proceedings of the 2014 ACM SIGMOD International Conference on Management of Data (2014)

  2. 2.

    Bertino, E.: Data Protection from Insider Threats. Synthesis Lecture on Data Management. Morgan & Claypool, San Rafael (2012)

    Google Scholar 

  3. 3.

    Bishop, M., Engle, S., Peisert, S., Whalen, S., Gates, C.: We have met the enemy and he is us. In: Proceedings of the 2008 Workshop on New Security Paradigms (2008)

  4. 4.

    Biskup, J., Embley, D.W., Lochner, J.-H.: Reducing inference control to access control for normalized database schemas. Inf. Process. Lett. 106(1):8–12 (2008)

  5. 5.

    Biskup, J., Hartmann, S., Link, S., Lochner, J.-H.: Efficient inference control for open relational queries. In: Proceedings of the 24th Annual IFIP WG 11.3 Working Conference on Data and Applications Security and Privacy (2010)

  6. 6.

    Brodsky, A., Farkas, C., Jajodia, S.: Secure databases: constraints, inference channels, and monitoring disclosures. IEEE Trans. Knowl. Data Eng. 12(6):900–919 (2000)

  7. 7.

    Delugach, H.S., Hinke, T.H.: Wizard: a database inference analysis and detection system. IEEE Trans. Knowl. Data Eng. 8(1):56–66 (1996)

  8. 8.

    Denning, D.E.: Commutative filters for reducing inference threats in multilevel database systems. In: Security and Privacy, 1985 IEEE Symposium on (1985)

  9. 9.

    Denning, D.E.: Annual Review of Computer Science: Vol. 3, chapter Database Security (1988)

  10. 10.

    Farkas, C., Jajodia, S.: The inference problem: a survey. ACM SIGKDD Explor. Newsl. 4(2):6–11 (2002)

  11. 11.

    Hale, J., Shenoi, S.: Catalytic inference analysis: detecting inference threats due to knowledge discovery. In: Security and Privacy, 1997. Proceedings, 1997 IEEE Symposium on (1997)

  12. 12.

    Morgenstern, M.: Controlling logical inference in multilevel database systems. In: Proceedings of the 1988 IEEE Conference on Security and Privacy (1988)

  13. 13.

    Qian, X., Stickel, M. E., Karp, P. D., Lunt, T. F., Carvey, T. D.: Detection and elimination of inference channels in multilevel relational database systems. In: Proceedings of the 1993 IEEE Symposium on Security and Privacy (1993)

  14. 14.

    Rizvi, S., Mendelzon, A., Sudarshan, S., Roy, P.: Extending query rewriting techniques for fine-grained access control. In: Proceedings of the 2004 ACM SIGMOD International Conference on Management of Data (2004)

  15. 15.

    Thuraisingham, B.M.: Security checking in relational database management systems augmented with inference engines. Comput. Secur. 6(6):479–492 (1987)

  16. 16.

    Thuraisingham, B.M.: Security issues for data warehousing and data mining. In: Proceedings of the Tenth Annual IFIP TC11/WG11.3 International Conference on Database Security: Volume X: Status and Prospects: Status and Prospects (1997)

  17. 17.

    Toland, T.S., Farkas, C., Eastman, C. M.: The inference problem: maintaining maximal availability in the presence of database updates. Comput. Secur. 29(1):88–103 (2010)

  18. 18.

    Wang, Q., Yu, T., Li, N., Lobo, J., Bertino, E., Irwin, K., Byun, J.-W.: On the correctness criteria of fine-grained access control in relational databases. In: Proceedings of the 33rd International Conference on Very Large Data Bases (2007)

  19. 19.

    Woodruff, D., Staddon, J.: Private inference control. In: Proceedings of the 11th ACM Conference on Computer and Communications Security (2004)

Download references

Acknowledgments

The research presented in this paper was partially funded by the European Office of Aerospace Research and Development (EOARD) and the Air Force for Scientific Research (ASFOR). We would like to thank authors of [1] for their remarkable help in providing the dataset that have been exploited in test phase and in setting the query generator. Authors would like to thank the anonymous reviewers for their valuable comments and suggestions to improve the quality of the paper.

Author information

Affiliations

Authors

Corresponding author

Correspondence to Elena Ferrari.

Appendix: Security proofs

Appendix: Security proofs

Correctness

Proof

We prove Theorem 1 by showing that if \(\exists t^{\star } \in Rs(q^{rw})\) such that \(\exists a \in \mathtt{schema(}Rs(q^{rw})\mathtt{)}\), for which neither P.1 nor P.2 hold, then a contradiction arises.

If P.1 does not hold, it means that there is no policy authorizing \(t^{\star }\), thus \(a^{\star }\) is not contained into \(authorizedAttributes_{q}\), but it is still in \(requestedAttributes_{q}\) computed in Line 4 of Algorithm 5.1. The algorithm then checks each table specified in F \(_{q}\). When the one, say \(T^{\star }\), to which \(t^{\star }\) belongs is considered, the if condition in Line 7 is satisfied. After the execution of Line 8, \(unauthorizedAttributes_{q}\) contains \(a^{\star }\). When \(a^{\star }\) is considered in for cycle in Line 10, since P.2 does not hold, we might have two cases: (i) There exists no data dependency that implies attribute \(a^{\star }\); (ii) there exists no data dependency that implies attribute \(a^{\star }\) such that the dependency determinant is explicitly authorized for u.

Let us consider the first case (i), that is, that no data dependency in DD implies attribute \(a^{\star }\). As such, the dependenciesForAttribute set computed at Line 10 is empty. Therefore, the conditional statement at Line 11 is not verified and the computation goes at Line 28, where the algorithm stops and returns a message to inform that the query is not authorized. Thus, a contradiction arises.

In the second case (ii), there exists at least one data dependency \(dd^{\star }\) with \(a^{\star }\) \(\in \) \(dd^{\star }.Dep\), but there is no access control policy authorizing u to access \(dd^{\star }.Det\). In this case, the condition in Line 11 is satisfied (i.e., dependenciesForAttribute \(\ne \) \(\emptyset \)), but the \(PoliciesForDeterminant\) set is empty. This brings the algorithm to remove \(dd^{\star }\) from dependenciesForAttribute, thus making the if condition in Line 16 false. As such, algorithm jumps to line 26, stops, and returns an unauthorized message. Thus, a contradiction arises. \(\square \)

Completeness

Proof

Similarly to Theorem 1, we prove Theorem 2 by contradiction. In particular, we show that if there exists a tuple \(t^{\star }\in Rs(q)\) such that there exists an attribute \(a^{\star }\in \mathtt{schema(}Rs(q)\mathtt{)}\) to which properties P.1 and P.2 do not apply and \(t^{\star }\in Rs(q^{rw})\), then a contradiction arises.

If P.1 does not hold for \(a^{\star }\), it implies that there is no policy authorizing \(t^{\star }\). Thus, similarly to the proof of Theorem 1, the if condition in Line 7 is satisfied. However, since P.2 does not apply, it means that: (i) there exists no data dependency that implies attribute \(a^{\star }\); (ii) there exists no data dependency that implies attribute \(a^{\star }\) such that the dependency determinant is explicitly authorized for u.

Let us consider the first case (i). Since no data dependency is available, the if condition in Line 11 is not satisfied, thus Algorithm jumps to Line 28, stops, and returns an unauthorized message. As such, a contradiction arises, since the assumption that \(t^{\star }\in Rs(q^{rw})\) implies that a rewritten query is returned.

In the second case (ii), we have that there exists at least one data dependency \(dd^{\star }\) with \(a^{\star }\) \(\in \) \(dd^{\star }.Dep\), but there is no access control policy authorizing u to access \(dd^{\star }.Det\). In this case, the if condition in Line 11 is satisfied (i.e., dependenciesForAttribute \(\ne \) \(\emptyset \)), but the PoliciesForDeterminant set is empty. This brings the algorithm to remove \(dd^{\star }\) from dependenciesForAttribute, thus making the if condition in Line 16 false. As such, algorithm jumps to line 26, stops, and returns an unauthorized message. Thus, a contradiction arises, since the assumption that \(t^{\star }\in Rs(q^{rw})\) implies that a rewritten query is returned. \(\square \)

Rights and permissions

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Albertini, D.A., Carminati, B. & Ferrari, E. An extended access control mechanism exploiting data dependencies. Int. J. Inf. Secur. 16, 75–89 (2017). https://doi.org/10.1007/s10207-016-0322-4

Download citation

Keywords

  • Query rewriting
  • Data dependencies
  • Functional dependencies
  • Discretionary access control