Commit 3c2155b8 authored by Keir Fraser's avatar Keir Fraser

Remove unmaintained Access Control Module (ACM) from hypervisor.

Signed-off-by: default avatarKeir Fraser <keir@xen.org>
parent f40d30c4
......@@ -153,11 +153,9 @@ CFLAGS += $(foreach i, $(EXTRA_INCLUDES), -I$(i))
EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
# Enable XSM security module. Enabling XSM requires selection of an
# XSM security module (FLASK_ENABLE or ACM_SECURITY).
# Enable XSM security module (by default, Flask).
XSM_ENABLE ?= n
FLASK_ENABLE ?= n
ACM_SECURITY ?= n
FLASK_ENABLE ?= $(XSM_ENABLE)
# Download GIT repositories via HTTP or GIT's own protocol?
# GIT's protocol is faster and more robust, when it works at all (firewalls
......
This diff is collapsed.
This diff is collapsed.
......@@ -1007,384 +1007,6 @@ Delete a vnet.
=back
=head1 ACCESS CONTROL SUBCOMMANDS
Access Control in Xen consists of two components: (i) The Access
Control Policy (ACP) defines security labels and access rules based on
these labels. (ii) The Access Control Module (ACM) makes access control
decisions by interpreting the policy when domains require to
communicate or to access resources. The Xen access control has
sufficient mechanisms in place to enforce the access decisions even
against maliciously acting user domains (mandatory access control).
Access rights for domains in Xen are determined by the domain security
label only and not based on the domain Name or ID. The ACP specifies
security labels that can then be assigned to domains and
resources. Every domain must be assigned exactly one security label,
otherwise access control decisions could become indeterministic. ACPs
are distinguished by their name, which is a parameter to most of the
subcommands described below. Currently, the ACP specifies two ways to
interpret labels:
(1) Simple Type Enforcement: Labels are interpreted to decide access
of domains to communication means and virtual or physical
resources. Communication between domains as well as access to
resources are forbidden by default and can only take place if they are
explicitly allowed by the security policy. The proper assignment of
labels to domains controls the sharing of information (directly
through communication or indirectly through shared resources) between
domains. This interpretation allows to control the overt (intended)
communication channels in Xen.
(2) Chinese Wall: Labels are interpreted to decide which domains can
co-exist (be run simultaneously) on the same system. This
interpretation allows to prevent direct covert (unintended) channels
and mitigates risks caused by imperfect core domain isolation
(trade-off between security and other system requirements). For a
short introduction to covert channels, please refer to
http://www.multicians.org/timing-chn.html.
The following subcommands help you to manage security policies in Xen
and to assign security labels to domains. To enable access control
security in Xen, you must compile Xen with ACM support enabled as
described under "Configuring Security" below. There, you will find
also examples of each subcommand described here.
=over 4
=item B<setpolicy> ACM I<policy>
Makes the given ACM policy available to xend as a I<xend-managed policy>.
The policy is compiled and a mapping (.map) as well as a binary (.bin)
version of the policy is created. The policy is loaded and the system's
bootloader is prepared to boot the system with this policy the next time
it is started.
=back
=over 4
I<policy> is a dot-separated list of names. The last part is the file
name pre-fix for the policy XML file. The preceding name parts are
translated into the local path pointing to the policy XML file
relative to the global policy root directory
(/etc/xen/acm-security/policies). For example,
example.chwall_ste.client_v1 denotes the policy file
example/chwall_ste/client_v1-security_policy.xml relative to the
global policy root directory.
=back
=over 4
=item B<resetpolicy>
Reset the system's policy to the default state where the DEFAULT policy
is loaded and enforced. This operation may fail if for example guest VMs are
running and and one of them uses a different label than what Domain-0
does. It is best to make sure that no guests are running before issuing
this command.
=item B<getpolicy> [--dumpxml]
Displays information about the current xend-managed policy, such as
name and type of the policy, the uuid xend has assigned to it on the
local system, the version of the XML representation and the status
of the policy, such as whether it is currently loaded into Xen or
whether the policy is automatically loaded during system boot. With
the I<--dumpxml> option, the XML representation of the policy is
displayed.
=item B<dumppolicy>
Prints the current security policy state information of Xen.
=item B<labels> [I<policy>] [B<type=dom>|B<res>|B<any>]
Lists all labels of a I<type> (domain, resource, or both) that are
defined in the I<policy>. Unless specified, the default I<policy> is
the currently enforced access control policy. The default for I<type>
is 'dom'. The labels are arranged in alphabetical order.
=item B<addlabel> I<label> B<dom> I<configfile> [I<policy>]
=item B<addlabel> I<label> B<mgt> I<domain name> [I<policy type>:I<policy>]
=item B<addlabel> I<label> B<res> I<resource> [I<policy>]
=item B<addlabel> I<label> B<vif-idx> I<domain name> [I<policy type>:I<policy>]
Adds the security label with name I<label> to a domain
I<configfile> (dom), a Xend-managed domain (mgt), to the global resource label
file for the given I<resource> (res), or to a managed domain's virtual network
interface (vif) that is specified by its index. Unless specified,
the default I<policy> is the currently enforced access control policy.
This subcommand also verifies that the I<policy> definition supports the
specified I<label> name.
The only I<policy type> that is currently supported is I<ACM>.
=item B<rmlabel> B<dom> I<configfile>
=item B<rmlabel> B<mgt> I<domain name>
=item B<rmlabel> B<res> I<resource>
=item B<rmlabel> B<vif-idx> I<domain name>
Works the same as the B<addlabel> command (above), except that this
command will remove the label from the domain I<configfile> (dom),
a Xend-managed domain (mgt), the global resource label file (res),
or a managed domain's network interface (vif).
=item B<getlabel> B<dom> I<configfile>
=item B<getlabel> B<mgt> I<domain name>
=item B<getlabel> B<res> I<resource>
=item B<getlabel> B<vif-idx> I<domain name>
Shows the label for a domain's configuration in the given I<configfile>,
a xend-managed domain (mgt), a resource, or a managed domain's network
interface (vif).
=item B<resources>
Lists all resources in the global resource label file. Each resource
is listed with its associated label and policy name.
=item B<dry-run> I<configfile>
Determines if the specified I<configfile> describes a domain with a valid
security configuration for type enforcement. The test shows the policy
decision made for each resource label against the domain label as well as
the overall decision.
B<CONFIGURING SECURITY>
=over 4
In xen_source_dir/Config.mk set the following parameter:
XSM_ENABLE ?= y
ACM_SECURITY ?= y
Then recompile and install xen and the security tools and then reboot:
cd xen_source_dir; make clean; make install
reboot into Xen
=back
B<RESETTING THE SYSTEM'S SECURITY>
=over 4
To set the system's security policy enforcement into its default state,
the follow command can be issued. Make sure that no guests are running
while doing this.
xm resetpolicy
After this command has successfully completed, the system's DEFAULT policy
is enforced.
=back
B<SETTING A SECURITY POLICY>
=over 4
This step sets the system's policy and automatically loads it into Xen
for enforcement.
xm setpolicy ACM example.client_v1
=back
B<LISTING SECURITY LABELS>
=over 4
This subcommand shows all labels that are defined and which can be
attached to domains.
xm labels example.client_v1 type=dom
will print for our example policy:
dom_BoincClient
dom_Fun
dom_HomeBanking
dom_NetworkDomain
dom_StorageDomain
dom_SystemManagement
=back
B<ATTACHING A SECURITY LABEL TO A DOMAIN>
=over 4
The B<addlabel> subcommand can attach a security label to a domain
configuration file, here a HomeBanking label. The example policy
ensures that this domain does not share information with other
non-homebanking user domains (i.e., domains labeled as dom_Fun or
dom_Boinc) and that it will not run simultaneously with domains
labeled as dom_Fun.
We assume that the specified myconfig.xm configuration file actually
instantiates a domain that runs workloads related to home-banking,
probably just a browser environment for online-banking.
xm addlabel dom_HomeBanking dom myconfig.xm
The very simple configuration file might now look as printed
below. The B<addlabel> subcommand added the B<access_control> entry at
the end of the file, consisting of a label name and the policy that
specifies this label name:
kernel = "/boot/vmlinuz-2.6.16-xen"
ramdisk="/boot/U1_home_banking_ramdisk.img"
memory = 164
name = "homebanking"
vif = [ '' ]
dhcp = "dhcp"
access_control = ['policy=example.chwall_ste.client_v1,
label=dom_HomeBanking']
Security labels must be assigned to domain configurations because
these labels are essential for making access control decisions as
early as during the configuration phase of a newly instantiated
domain. Consequently, a security-enabled Xen hypervisor will only
start domains that have a security label configured and whose security
label is consistent with the currently enforced policy. Otherwise,
starting the domain will fail with the error condition "operation not
permitted".
=back
B<ATTACHING A SECURITY LABEL TO A XEND-MANAGED DOMAIN>
=over 4
The addlabel subcommand supports labeling of domains that are managed
by xend. This includes domains that are currently running, such as for
example Domain-0, or those that are in a dormant state.
Depending on the state of the system, it is possible that the new label
is rejected. An example for a reason for the rejection of the relabeling
of a domain would be if a domain is currently allowed to
access its labeled resources but due to the new label would be prevented
from accessing one or more of them.
xm addlabel dom_Fun mgt Domain-0
This changes the label of Domain-0 to dom_Fun under the condition that
this new label of Domain-0 would not prevent any other domain from
accessing its resources that are provided through Domain-0, such as for
example network or block device access.
=back
B<ATTACHING A SECURITY LABEL TO A RESOURCE>
=over 4
The B<addlabel> subcommand can also be used to attach a security
label to a resource. Following the home banking example from above,
we can label a disk resource (e.g., a physical partition or a file)
to make it accessible to the home banking domain. The example policy
provides a resource label, res_LogicalDiskPartition1(hda1), that is
compatible with the HomeBanking domain label.
xm addlabel "res_LogicalDiskPartition1(hda1)" res phy:hda6
After labeling this disk resource, it can be attached to the domain
by adding a line to the domain configuration file. The line below
attaches this disk to the domain at boot time.
disk = [ 'phy:hda6,sda2,w' ]
Alternatively, the resource can be attached after booting the domain
by using the B<block-attach> subcommand.
xm block-attach homebanking phy:hda6 sda2 w
Note that labeled resources cannot be used when security is turned
off. Any attempt to use labeled resources with security turned off
will result in a failure with a corresponding error message. The
solution is to enable security or, if security is no longer desired,
to remove the resource label using the B<rmlabel> subcommand.
=back
B<STARTING AND LISTING LABELED DOMAINS>
=over 4
xm create myconfig.xm
xm list --label
Name ID ... Time(s) Label
homebanking 23 ... 4.4 dom_HomeBanking
Domain-0 0 ... 2658.8 dom_SystemManagement
=back
B<LISTING LABELED RESOURCES>
=over 4
xm resources
phy:hda6
type: ACM
policy: example.chwall_ste.client_v1
label: res_LogicalDiskPartition1(hda1)
file:/xen/disk_image/disk.img
type: ACM
policy: example.chwall_ste.client_v1
label: res_LogicalDiskPartition2(hda2)
=back
B<POLICY REPRESENTATIONS>
=over 4
We distinguish three representations of the Xen access control policy:
the source XML version, its binary counterpart, and a mapping
representation that enables the tools to deterministically translate
back and forth between label names of the XML policy and label
identifiers of the binary policy. All three versions must be kept
consistent to achieve predictable security guarantees.
The XML version is the version that users are supposed to create or
change, either by manually editing the XML file or by using the Xen
policy generation tool (B<xensec_gen>). After changing the XML file,
run the B<setpolicy> subcommand to ensure that the new policy is
available to xend. Use, for example, the subcommand
B<activatepolicy> to activate the changes during the next system
reboot.
The binary version of the policy is derived from the XML policy by
tokenizing the specified labels and is used inside Xen only. It is
created with the B<setpolicy> subcommand. Essentially, the binary
version is much more compact than the XML version and is easier to
evaluate during access control decisions.
The mapping version of the policy is created during the XML-to-binary
policy translation (B<setpolicy>) and is used by xend and the management
tools to translate between label names used as input to the tools and
their binary identifiers (ssidrefs) used inside Xen.
=back
=back
=head1 SEE ALSO
B<xmdomain.cfg>(5), B<xentop>(1)
......
......@@ -11,7 +11,6 @@ Xen XSM:FLASK configuration
XSM_ENABLE ?= y
FLASK_ENABLE ?= y
ACM_SECURITY ?= n
NB: Only one security module can be selected at a time. If no module is
selected, then the default DUMMY module will be enforced. The DUMMY module
......
......@@ -2177,47 +2177,6 @@ Most of the above are best understood by looking at the code
implementing them (in {\tt xen/common/dom0\_ops.c}) and in
the user-space tools that use them (mostly in {\tt tools/libxc}).
\section{Access Control Module Hypercalls}
\label{s:acmops}
Hypercalls relating to the management of the Access Control Module are
also restricted to domain 0 access for now. For more details on any or
all of these, please see {\tt xen/include/public/acm\_ops.h}. A
complete list is given below:
\begin{quote}
\hypercall{acm\_op(int cmd, void *args)}
This hypercall can be used to configure the state of the ACM, query
that state, request access control decisions and dump additional
information.
\begin{description}
\item [ACMOP\_SETPOLICY:] set the access control policy
\item [ACMOP\_GETPOLICY:] get the current access control policy and
status
\item [ACMOP\_DUMPSTATS:] get current access control hook invocation
statistics
\item [ACMOP\_GETSSID:] get security access control information for a
domain
\item [ACMOP\_GETDECISION:] get access decision based on the currently
enforced access control policy
\end{description}
\end{quote}
Most of the above are best understood by looking at the code
implementing them (in {\tt xen/common/acm\_ops.c}) and in the
user-space tools that use them (mostly in {\tt tools/security} and
{\tt tools/python/xen/lowlevel/acm}).
\section{Debugging Hypercalls}
A few additional hypercalls are mainly useful for debugging:
......
This diff is collapsed.
......@@ -13,7 +13,6 @@ SUBDIRS-y += hotplug
SUBDIRS-y += xentrace
SUBDIRS-$(CONFIG_XCUTILS) += xcutils
SUBDIRS-$(CONFIG_X86) += firmware
SUBDIRS-$(ACM_SECURITY) += security
SUBDIRS-y += console
SUBDIRS-y += xenmon
SUBDIRS-$(VTPM_TOOLS) += vtpm_manager
......
......@@ -7,12 +7,12 @@ all install: check-build
# Check this machine is OK for building on.
.PHONY: check-build
check-build:
PYTHON=$(PYTHON) LIBXENAPI_BINDINGS=$(LIBXENAPI_BINDINGS) ACM_SECURITY=$(ACM_SECURITY) ./chk build
PYTHON=$(PYTHON) LIBXENAPI_BINDINGS=$(LIBXENAPI_BINDINGS) ./chk build
# Check this machine is OK for installing on.
.PHONY: check-install
check-install:
PYTHON=$(PYTHON) LIBXENAPI_BINDINGS=$(LIBXENAPI_BINDINGS) ACM_SECURITY=$(ACM_SECURITY) ./chk install
PYTHON=$(PYTHON) LIBXENAPI_BINDINGS=$(LIBXENAPI_BINDINGS) ./chk install
.PHONY: clean
clean:
......
......@@ -3,7 +3,7 @@
. ./funcs.sh
if [ ! "$LIBXENAPI_BINDINGS" = "y" -a ! "$ACM_SECURITY" = "y" ]
if [ ! "$LIBXENAPI_BINDINGS" = "y" ]
then
echo -n "unused, "
exit 0
......
......@@ -13,7 +13,6 @@ CTRL_SRCS-y += xc_domain.c
CTRL_SRCS-y += xc_evtchn.c
CTRL_SRCS-y += xc_gnttab.c
CTRL_SRCS-y += xc_misc.c
CTRL_SRCS-y += xc_acm.c
CTRL_SRCS-y += xc_flask.c
CTRL_SRCS-y += xc_physdev.c
CTRL_SRCS-y += xc_private.c
......
/******************************************************************************
* xc_acm.c
*
* Copyright (C) 2005, 2006 IBM Corporation, R Sailer
*
* Copyright 2006 Sun Microsystems, Inc. All rights reserved.
* Use is subject to license terms.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation;
* version 2.1 of the License.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
#include "xc_private.h"
int xc_acm_op(xc_interface *xch, int cmd, void *arg, unsigned long arg_size)
{
int ret;
DECLARE_HYPERCALL;
DECLARE_HYPERCALL_BUFFER(struct xen_acmctl, acmctl);
acmctl = xc_hypercall_buffer_alloc(xch, acmctl, sizeof(*acmctl));
if ( acmctl == NULL )
{
PERROR("Could not allocate memory for ACM OP hypercall");
return -EFAULT;
}
switch (cmd) {
case ACMOP_setpolicy: {
struct acm_setpolicy *setpolicy = (struct acm_setpolicy *)arg;
memcpy(&acmctl->u.setpolicy,
setpolicy,
sizeof(struct acm_setpolicy));
}
break;
case ACMOP_getpolicy: {
struct acm_getpolicy *getpolicy = (struct acm_getpolicy *)arg;
memcpy(&acmctl->u.getpolicy,
getpolicy,
sizeof(struct acm_getpolicy));
}
break;
case ACMOP_dumpstats: {
struct acm_dumpstats *dumpstats = (struct acm_dumpstats *)arg;
memcpy(&acmctl->u.dumpstats,
dumpstats,
sizeof(struct acm_dumpstats));
}
break;
case ACMOP_getssid: {
struct acm_getssid *getssid = (struct acm_getssid *)arg;
memcpy(&acmctl->u.getssid,
getssid,
sizeof(struct acm_getssid));
}
break;
case ACMOP_getdecision: {
struct acm_getdecision *getdecision = (struct acm_getdecision *)arg;
memcpy(&acmctl->u.getdecision,
getdecision,
sizeof(struct acm_getdecision));
}
break;
case ACMOP_chgpolicy: {
struct acm_change_policy *change_policy = (struct acm_change_policy *)arg;
memcpy(&acmctl->u.change_policy,
change_policy,
sizeof(struct acm_change_policy));
}
break;
case ACMOP_relabeldoms: {
struct acm_relabel_doms *relabel_doms = (struct acm_relabel_doms *)arg;
memcpy(&acmctl->u.relabel_doms,
relabel_doms,
sizeof(struct acm_relabel_doms));
}
break;
}
acmctl->cmd = cmd;
acmctl->interface_version = ACM_INTERFACE_VERSION;
hypercall.op = __HYPERVISOR_xsm_op;
hypercall.arg[0] = HYPERCALL_BUFFER_AS_ARG(acmctl);
if ( (ret = do_xen_hypercall(xch, &hypercall)) < 0)
{
if ( errno == EACCES )
DPRINTF("acmctl operation failed -- need to"
" rebuild the user-space tool set?\n");
}
switch (cmd) {
case ACMOP_getdecision: {
struct acm_getdecision *getdecision = (struct acm_getdecision *)arg;
memcpy(getdecision,
&acmctl->u.getdecision,
sizeof(struct acm_getdecision));
break;
}
}
xc_hypercall_buffer_free(xch, acmctl);
return ret;
}
/*
* Local variables:
* mode: C
* c-set-style: "BSD"
* c-basic-offset: 4
* tab-width: 4
* indent-tabs-mode: nil
* End: