Finer access control framework over users, domains and operations.

Finer access control framework over users, domains and operations.

[Syunsuke HAYASHI]

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

Re: Finer access control framework over users, domains and operations.

[Ian Jackson]

Syunsuke HAYASHI writes ("[Xen-devel] Finer access control framework over 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.

In most deployments this problem is addressed by the use of (for
example) a web-based management interface layered on top of the
underlying xm machinery.

Do your users really need an structurally very similar interface to
that provided by xm or libvirt ?  If so then yes maybe you will need
to write a policy-enforcing proxy but this would be a very large
amount of work and I wouldn't recommend it as an approach unless
unavoidable.

If the users don't need an interface that looks like (say) xm, then
the system's overall administrator can provide a much simpler higher
interface - and this is typically done with a bit of semi-custom
scripting based on a webserver, ssh with command-restricted keys, or
tools like `userv'[1] or `sudo'.

I think you may find that this ad-hoc approach provides both a quicker
route to solving your problem, and also a result which will be more
finely tuned to your needs.

Generalised policy framework systems are inevitably complex (and thus
often buggy!) and hard to write, and, paradoxically they often turn
out to be inflexible when one actually tries to use them.

> ioctl approach:

As you seem to have figured out, this is a non-starter.  Much of the
functionality you are trying to provide access to lives in user-space
management processes like xend and the lvm tools.

> <?xml version="1.0" ?>

And my final comment is: please do not use XML for configuration
files.  It is almost wholly unsuited for this use.

XML is utterly awful to edit by hand, doesn't diff well, is vastly
overcomplex, encourages overcomplex configuration structures, requires
a huge amount of parsing infrastructure, is very slow to parse, and is
just plain ugly.  Just a personal opinion.

Ian.

[1] GNU userv, a security boundary tool
   http://www.chiark.greenend.org.uk/~ian/userv/
 Full disclosure: I'm plugging my own software here :-).

Re: Finer access control framework over users, domains and operations.

[Syunsuke HAYASHI]

Hi, Ian

We understand that the implementation of the ACM on the web layer is easy.
But we think that basic control tools of Xen (xm and libvirt) also need 
the ACM

It is necessary to realize the ACM which considers users, domains and 
operations.
We only know ways that control by the unit of users or processes.
Please let us know if there are other tools or ways that realize the ACM.

Thanks,


Ian Jackson wrote:
 > Syunsuke HAYASHI writes ("[Xen-devel] Finer access control framework 
over 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.
 >
 > In most deployments this problem is addressed by the use of (for
 > example) a web-based management interface layered on top of the
 > underlying xm machinery.
 >
 > Do your users really need an structurally very similar interface to
 > that provided by xm or libvirt ?  If so then yes maybe you will need
 > to write a policy-enforcing proxy but this would be a very large
 > amount of work and I wouldn't recommend it as an approach unless
 > unavoidable.

Re: Finer access control framework over users, domains and operations.

[Ian Jackson]

Syunsuke HAYASHI writes ("Re: [Xen-devel] Finer access control framework over users,	domains and operations."):
> We understand that the implementation of the ACM on the web layer is easy.
> But we think that basic control tools of Xen (xm and libvirt) also need 
> the ACM

I see.  Why ?

> It is necessary to realize the ACM which considers users, domains and 
> operations.
> We only know ways that control by the unit of users or processes.
> Please let us know if there are other tools or ways that realize the ACM.

I'm not sure what you mean by `realise the ACM'.  Earlier you said
`ACM' stood for `Access Control Module' which I'll take to assume
means just some kind of access control facility.  I assume `realise'
means `have.

So you seem to be saying that you need an access control facility that
`considers users, domains and operations'.  That kind of access
control seems to be exactly what is easily done at a web ui layer, as
I said.

Perhaps `Access Control Module' means something more specific.  If so
then what kind of something ?  And why do you need that rather than
another solution ?

It would be most helpful if you described your ultimate objectives, in
a solution-neutral way.

Ian.