[Xen-devel] Re: [Xense-devel] [PATCH] ACM: adding get_ssid command and cleanup

Reiner Sailer
Sat, 03 Sep 2005 02:53:10 -0000

David Palmer <dwpalmer.xense@gmail.com> wrote on 09/02/2005 02:41:28 PM:

> Reiner,
>
> I''ve looked over the code.  As input, it takes either an SSID or a
> DomainID.  If given a DomainID, it looks up the domain''s SSID.  It
> then returns two arrays of 0''s and 1''s.  One array is a
row from the
> STE-Type matrix and the other is a row from the ChWall-Type matrix
> corresponding to the given SSID.

More information explaining legitimate and envisioned use of this
function:
The get_ssid (get subject security identifier) command was mainly
introduced to allow device domains to retrieve the security related
information they need from the hypervisor. This way, they can enforce
access control on the virtual resources they are offering to other
domains. To do this, a device domain only needs to know those types of a
remote domain that it shares with this domain. In the future, we will
restrict domains other than the security management domain (currently
dom0) to those types.

We use get_ssid based on the domainID in device domains that need to know
the types of their peer domains requiring access (e.g., requesting to
mount a logical partition). This usually involves code "behind"
backend
interfaces in Xen.

We plan to use get_ssid based on the ssidref for resources (once resource
labeling is introduced) to control the allocation of physical resources
(e.g. peripherals) to domains according to the types of the domain to
which a peripheral is being assigned and the types of the peripheral (only
domains that share a type with the peripheral can own it).

> My question then: What constitutes a legitimate use vs. a clear
> abuse of this information?
> For example, lets say I create a domain that manages a resource.
> When another domain connects, the resource domain checks for a
> specific type using get_ssid() on the subject''s DomainID and
indexes
> one of the arrays with the type number.  If the type is set, then it
> provides the "Privileged" interface with the other domain.

Some background for the legitimate use of this function:
The access control decision of a device domain is yes/no to a request of a
remote domain to access a resource (e.g., connect a front-end virtual
block device driver in a user domain to a back-end virtual block device
driver in a device domain). It is not based on any specific operation but
only on the security types of the domains. The  "privileged" part
comes in
when a domain tries to use get_ssid on the hypervisor.

Your question seems to go towards operation granularity for access control
decisions, which is not what the current policies envision. We leave this
granularity to upper layers (inside domains) in Xen. I could re-formulate
your latter sentence: "If the type is set, then it allows access (any
access), otherwise it denies access to the resource." Denying access in
this context means, e.g., that connecting a front-end block device driver
to the respective back-end block device driver fails and a domain will not
be able to mount a drive (or access the network in case of network
front/back ends).

The hypervisor with the help of device domains does NOT control the
operation ("mount disk" or "send network traffic") but
controls general
access of domains to virtual resources (access to the storage domain''s
virtual disks, access to the network domains virtual network interfaces).
In this context, the hypervisor controls if a domain can communicate at
all to a device domain, the device domain then controls if a domain can
access a certain virtual resource.

>Is this legitimate or an abuse of the function?  Why or why not?

Using get_ssid is restricted to privileged domains. If the privileged
domain is a device domain, then it MUST enforce the hypervisor policy
(here Type Enforcement). To further restrict access in higher layers is
legitimate and envisioned in device domains. Offering other domains even
an unprivileged interface if they don''t share a type is a violation of
the
hypervisor STE policy; this is illegal in device domains. Using get_ssid
in any other privileged domain in the way you describe could / should be
considered abuse since:

a) the policy information is not used as intended and inconsistencies are
likely to evolve
b) predicting the effect of policy settings onto the enforcement becomes
increasingly difficult (even the simple STE policy now can define quite
complex relationships)

Resolution:
i) The privileged/unprivileged access control interface could be
implemented based on a separate policy/enforcement layer above and
independent of the hypervisor (inside the privileged domain).

ii) A different hypervisor security policy could be implemented that does
not conflict with your privileged/unprivileged interface interpretation.
At this point your example use of get_ssid becomes legitimate since it is
consistent with the interpretation of the hypervisor policy.

I hope this is helful.

Thanks

Reiner

> On 9/1/05, Reiner Sailer <sailer@us.ibm.com> wrote:
>
> This patch:
>
> * adds a get_ssid ACM command that allows privileged domains to
> retrieve types for either a given ssid reference or a given domain
> id (of a running domain); this command can be used to extend access
> control into device domains, e.g., to control network traffic
> currently moving through Domain 0 uncontrolled by the ACM policy
>
> * adds a script getlabel.sh that allows users inside Dom0 to
> retrieve the label for a given ssid reference or a given domain id
> (multiple labels might map onto a single ssid reference)
>
> * cleans up label-related code in tools/security by merging common
> functions into labelfuncs.sh
>
> * cleans up ACM code related to above changes (eventually
> approximating a common coding style)
>
> Comments welcome.
>
> Thanks
> Reiner
>
> Signed-off-by Reiner Sailer <sailer@us.ibm.com>
> Signed-off by Stefan Berger <stefanb@us.ibm.com>
>
>
>
> _______________________________________________
> Xense-devel mailing list
> Xense-devel@lists.xensource.com
> http://lists.xensource.com/xense-devel