Abstract
Attribute-Based Access Control (ABAC) is increasingly becoming popular due to its dynamic, flexible, portable, and scalable nature. Under ABAC, security policies (ABAC rules) are stated in terms of the attributes of the subject, the object and the environment. A subject is granted access to an object if their respective attribute values are satisfied against a set of ABAC rules. Typically hierarchical relationships exist among the subjects as well as the objects, where more specific subjects (objects) inherit the attributes from the general ones. As such, if a subject is allowed access to a general object, that subject is allowed to access all of its sub-types. This has been the general understanding and current ABAC enforcement and policy mining approaches follow this approach. However, in this article, we argue that the general understanding of the semantics of the ABAC is not always appropriate. Indeed, under certain semantics, the specific data may be more sensitive than that of its general counterpart. In that situation, if a subject is allowed access to a general type, it should not be allowed access to its sub-type, which is contrary to the current understanding and implementation. This paper is the first attempt in the literature to distinguish these two different ABAC semantics arising from the different semantics of object attributes themselves. We present concrete examples of these two semantics and demonstrate what can go wrong - both anecdotally as well as empirically - if one ignores the underlying semantics and inappropriately uses the existing enforcement and mining algorithms. We then present how existing algorithms can be modified so that no misconfigurations arise and security is ensured.