Information Technology Reference
In-Depth Information
type conflict occurs because there're two resembled virtual machines in different
domains which may confuse the VMM and admins.
The rule for SoD-C:
•
has Subject
(?
p
1
,
?
s
1)
∧
has Resource
(?
p
1
,
?
r
1)
∧
has Operation
(?
p
1
,
?
o
1)
∧
has Action
(?
p
1
,
?
a
1)
∧
has Subject
(?
p
2
,
?
s
2)
∧
has VM
(?
p
2
,
?
v
2)
∧
has Operation
(?
p
2
,
?
o
2)
∧
has Action
(?
p
2
,
?
a
2)
∧
has Subject Overlap
(?
s
1
,
?
s
2)
∧
has subResource
(?
v
2
,
?
r
1)
∧
same
(?
o
1
,
?
o
2)
∧¬
same
(?
a
1
,
?
a
2)
ₒ
has SoDC
(?
p
1
,
?
p
2)
This rule means that two policies which share overlapped subjects, resources
and operations must have consistent actions, or this may cause a conflict of SoD-
C type because the policy enforcement mechanism have no idea which policy to
follow.
We find out that all these rules actually share similar forms which can be ex-
tracted into tuples like Policy (Subject, Resource, Operation, Action) in which
Policy is the tuple key which governs other elements. In fact, we can divide a rule
into 3 parts: aliating declarations within respective Policy instance, contradic-
tory declarations between member elements and conflict declaration between
policies. Apparently, if one policy's elements are constructed incompatible with
another one's, it will contribute to the possible conflicts between their policies.
5 Implementaion and Experiments
VRBAC Visualizer and Conflict Checker (VVCC), the prototype system, is im-
plemented in one of the most popular virtualized environments: Microsoft Active
Directory and Xen Cloud Platform (XCP). The architecture of our virtualized
environment is shown in Fig. 6 in which VVCC lies at the third level. Various
APIs are employed to help collect the data of VRBAC policies automatically,
including Active Directory Service Interface (ADSI), Windows Management In-
strumentation (WMI), Microsoft Remote Procedure Call (MSRPC), and APIs
of Xen. Besides XCP, we also give it a try in the VMware platform and feel glad
to find it's almost compatible with our VVCC system.
The policy data collected in the previous step will be transformed into ABox
style and then delivered to RacerPro engine for reasoning. Via nRQL (new Rac-
erPro Query Language) interface, VRBAC policy conflicts are retrieved and
analyzed.
The sketch map for of conflict checking results is shown in Fig. 7. There we
can see a SoD-C type conflict occurs between role NRDC1001 AND NSFC0902.
It's because filex has denied alice's access via role NRDC1001 from Domain1,
however, the data store where the file is actually stored is in the charge of
NSFC0902 from Domain2, which alice inherits some of her permissions from.
So it's inappropriate to both permit and deny one's access simultaneously in
vrbac policies. besides the sketch map, there's also a textual report available for
detailed information such as type, position of a conflict and the cause that leads
to the conflict, which is shown in Table 1. the number in “No.” column indicates
