Finer access control framework over users, domains and operations.

[Syunsuke HAYASHI <syunsuke@jp.fujitsu.com>]

Hi, all

We propose an access control framework which considers users, domains
and operations.

The current implementation exclusively allows root to control guest
domains.
Guest administrators have to switch to root so they can bring their own
guest domains up and down.

To solve this problem, Xen should introduce a framework where the root's
privileges are split into restricted roles.
Every guest administrator controls concerning guest domains with a part
of the least privilege with these roles supplied.

Figure 1 presents an example of the access control.

            +--------+    +--------+        +-------+
            | userA  |    | userB  |        | root  |
            +--+--+--+    +--------+        +---+---+
     operation |  | operation                   | delegate the authority
        to VM1 |  | to VM2                      v to userA
     +---------+--+----------------+    +-------+-------+
     |  Access Control Module      +----+ ACL Policy DB |
     +---------+--+----------------+    +---------------+
               |  |
        +------+  +-----+
        |pass           |fail
        v               v
    +---+---+       +---+---+
    |  VM1  |       |  VM2  |
    +-------+       +-------+

     Figure 1. An example of the access control by a domain administrator

The Access Control Module (ACM) determines if an operation is permitted
based on the Access Control Policy DB.
Concretely, when a user is going to submit a comand to VM, the ACM
checks if the tuple (user, command, VM) is valid with respect to the ACL
Policy DB.
For example, as depicted in figure 1, userA can operate VM1 but cannot
operate VM2 because the ACL Policy DB states so.


Figure 2 shows the control path of Xen and the location of ACM in our
implementation.
Marked as "*" are the developed ACMs for this framework.
They are secured-xm, secured-libvirt and virt-manager.
Secured-xen-API is under development, though.

            [Others]      [console/shell]    [virt-manager*]
            (GUI/CLI)    (CLI)       (CLI)     (GUI)
                v          v           v         v
[Dom0]         |          |           |         |
           (Xen-API)      (xm)      (virsh)  (libvirt-API)
                |          |           |         |
  +-------------+--*+ +----+------*+ +-+---------+----*+
  | secured-xen-API | | secured-xm | | secured-libvirt |
  +=================+ +============+ +=================+
  |     xen-API     | |      xm    | |   libvirt(API)  |
  +-------------+---+ +----+-------+ +-+--+------+-----+
                |          |           |  |      |
                |          |   +-------+  |      |
                |          |   |          |      |
                v          v   v          v      |
              +-+----------+---+-+   +----+----+ |
              |      xend        |<=>|xenstored| |
              +-------+----------+   +---------+ |
                      |                          |
                      v                          |
              +-------+-------+                  |
              |     libxc     |                  |
              +-------+-------+                  |
                      |                          |
                      v                          v
              +-------+--------------------------+-+
              |              ioctl                 |
              +------------------------------------+

     Figure 2. Control path of Xen and Access Control Modules

We internally discussed which component should have ACM feature and
concluded xm/libvirt are the best.
But there was at least one another candidate, which was ioctl.
The brief summary is:

xm/libvirt approach:
* is able to keep implementations simple because a xen operation to be
controlled has one-to-one relation to a xm/libvirt command (pros.).
* requires each individual implementation for xm and libvirt (cons.).

ioctl approach:
* supports both xend and libvirt in a single implementaion (pros.).
* is complecated in terms of implementation because some xen operations
have one-to-many relations to ioctls.  We have to resolve what xen
operation is submitted at the ioctl layer (cons.).

Since we are interested in the framework that realizes access control in
terms of user, operation and domain, xm/libvirt approach handling these
entities in a straightforward way seems promising.


Configuration files define entities and relations based on Role-based
Access Control (RBAC) model[1].
The concrete model employed here is:

   USERS <--(UA)--> ROLES <--(PA)--> PRMS(OBS,OPS)

Term definitions are follows.
   - USERS: a set of users
   - ROLES: a set of roles
   - PRMS(Permissions): the permission to the role
   - OBS(Objects): the objects which applies ACL
   - OPS(Operations): operation to the object
   - UA(User Assignment):  define user role relation
   - PA(Permission Assignment): define role and permission relation

These entities and relations are defined in the separate two files:

   UA file:
     defines the relations between user and role, as well as user names.
   PA file:
     defines the relations between role and permission, as well as
     operations and VM names.
An example is at the end of this document.

Root is responsible for editing UA and PA file to give a user a
permission to control a certain VM.

Here we show the example of UA and PA definition files.

[UA file]
<?xml version="1.0" ?>
<UserConfiguration>
   <User name="hostManager">          <-- User account name
     <UserRole role="HostOSManager"/> <-- Role name
   </User>
   <User name="user-admin">
     <UserRole role="Administrator"/>
     <UserRole role="PolicyManager"/>
   </User>
</UserConfiguration>

[PA file]
<?xml version="1.0" ?>
<RolePolicyDefinition>
   <Role name="HostOSManager">    <-- Role name
     <ManageVM type="individual"> <-- "individual" means for one guest VM
       <VM name="Domain-0"/>      <-- VM name for operating
     </ManageVM>
     <ControlOperation>
       <Accept>
         <operation id="2"/>      <-- Operation ID allowed to execute
         <operation id="3"/>
         <operation id="4"/>
         .................
         <operation id="62"/>
         <operation id="63"/>
       </Accept>
     </ControlOperation>
   </Role>
   <Role name="Administrator">
     <ManageVM type="individual">
       <VM name="Domain-0"/>
     </ManageVM>
     <ControlOperation>
       <Accept>
         <operation id="16"/>
       </Accept>
     </ControlOperation>
   </Role>
   <Role name="PolicyManager">
     <ManageVM type="individual">
       <VM name="Domain-0"/>
     </ManageVM>
     <ControlOperation>
       <Accept>
         <operation id="16"/>
       </Accept>
     </ControlOperation>
   </Role>
</RolePolicyDefinition>


References
==========================
[1] David F.Ferraiolo. et al., “Proposed NIST Standard for Role-Based
Access Control”, ACM Transaction on Institute and System Security,
Vol.4, No.3, August 2001, pp224-274.

Any comments are welcome.
Please let us know if there is a mailing list more appropriate than this
ML.

Best regards,

Syunsuke HAYASHI
Yutaka EZAKI
Masaki KANNO
Atsushi SAKAI