[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xense-devel] [PATCH] ACM: adding get_ssid command and cleanup
- To: Reiner Sailer <sailer@xxxxxxxxxx>
- From: David Palmer <dwpalmer.xense@xxxxxxxxx>
- Date: Sat, 3 Sep 2005 09:49:01 -0700
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Stefan Berger <stefanb@xxxxxxxxxx>, xense-devel@xxxxxxxxxxxxxxxxxxx
- Delivery-date: Sat, 03 Sep 2005 16:46:50 +0000
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mth36ztf0yNmFIBwlNTv8lUs8tsmZLcOruYZuk+ZgiSpqhBn6x3CILOzqGXhq7fyaDk6fWqilxu0i+3lzdOQ0/lU3HOLZ1xmzIBBG5xr0bwEHvsJ93YNxpAFUA5L0V9qFf12Qw82ZItKKPP4XlRTXW2/qWe5M9Yp1yaIY9z1EfE=
- List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
Yes, that helps considerably. I had the mistaken impression that
were implementing the Flask architecture. From the papers I've
it calls for object managers and a security server. Each object
is only concerned with object specific knowledge for policy
enforcement. Object managers rely on a central security server to
decisions. The security server has the sole responsibility of
interpreting the policy. This is clearly not the architecture you
envision for sHype.
Instead, what I hear you saying sounds like a collection of
resource reference monitors that follow a global policy that applies to
all reference monitors.
1. Each reference monitor makes policy decisions and enforces them for its resources.
2. A central policy server is used to provide the relevant portions of the global policy to the reference monitors.
3. Each reference monitor faithfully interprets the global policy according to the common policy semantics.
4. Each reference monitor enforces the global policy in that it does
not allow any more access than what is permitted by the policy
semantics. It may
choose to grant less access as long as it does not change the meaning
of the global policy.
For example, lets consider the case where I have a domain that
provides both a "privileged" and "unprivileged" interface to its
resources. The global policy allows a red and a black domain to each
connect to the resource domain. The resource domain may choose to
provide different levels of access to red and black. It should not
interpret the global policy differently, but instead it can honor a
local policy that names the red and black domains.
Have you published a paper detailing this architecture and how it
compares with other architectures? It would be interesting to go over
it in detail and see what you have learned about the approach.
In your messages, you note that it is important that the global policy
has a consistent meaning for all reference monitors, and that the
architecture supports the ability to change the meaning of the policy
in the future.
1. Doesn't optimizing the policy decision logic for each resource
monitor increase the risk that there will be differences in how each of
them interprets the global policy?
Although we all try to write perfect code, we certainly have to accept
that it doesn't generally happen. There is an advantage to having
a single golden implementation where defects can be fixed such that all
resource managers benefit. Independent optimizations for the
policy decision logic in each resource monitor increases the chances
for defects that have to be fix independently. Unfortunately,
testing tends not to work well for eliminating security vulnerabilities
as it only finds the few that were tested for.
2. How can semantic changes in the global policy be made?
If each resource monitor is responsible for interpreting the policy
consistently with each other, aren't they locked into the specific
semantics of the policy they understand? In the worse case, won't
this lead to needing to rewrite each reference monitor in order to add
or alter the policy semantics?
I'm concerned that if I start implementing my own reference monitor
with the given get_ssid() function, I'll end up having to rewrite it
completely as it won't be consistent with the solution you have in mind
for addressing the goals of providing consistent policy semantics and
allowing them to be changed in the future.
On 9/2/05, Reiner Sailer <sailer@xxxxxxxxxx> wrote:
David Palmer <dwpalmer.xense@xxxxxxxxx> wrote
on 09/02/2005 02:41:28 PM:
> I've looked over the code. As input, it takes either an SSID
> DomainID. If given a DomainID, it looks up the domain's SSID.
> then returns two arrays of 0's and 1's. One array is a row from
> 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
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,
> 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)
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.
> On 9/1/05, Reiner Sailer <sailer@xxxxxxxxxx>
> 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.
> Signed-off-by Reiner Sailer <sailer@xxxxxxxxxx>
> Signed-off by Stefan Berger <stefanb@xxxxxxxxxx>
> Xense-devel mailing list
Xense-devel mailing list