Linker command lines are order-sensitive.
Move linker options -Lfoo -lfoo from LDFLAGS to LDLIBS and place this new
variable after the objects to link. This resolves build errors in xenpagin
and blktap with recent toolchains.
rename SHLIB_CFLAGS to SHLIB_LDFLAGS
rename LDFLAGS_* to LDLIBS_*
move LDFLAGS usage after CFLAGS in CC calls
remove stale comments in xenpaging Makefile
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
For now hardcode /etc w/o a prefix as there are hardcoded
config paths in the code which would break otherwise.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
We change all invocations of setup.py as follows:
* use $(PYTHON) instead of `python' so that the user can specify
an alternative python version if they need to. If not set it
defaults to `python' in Config.mk.
* pass --prefix=$(PREFIX) via a new make variable
$(PYTHON_PREFIX_ARG). This allows a user to suppress the
--prefix=... argument entirely by setting PYTHON_PREFIX_ARG=''.
This will work around the bug described here
https://bugs.launchpad.net/ubuntu/+bug/362570
where passing --prefix=/usr/local (which ought to have no effect as
/usr/local is the default prefix) changes which subdirectory
distutils chooses, and results in the files being installed in
site-packages which is not on the default search path.
Users not affected by this python packaging bug should not set
PYTHON_PREFIX_ARG and their builds will not be affected. (Provided
PREFIX did not contain spaces. People who put spaces in PREFIX are
being quite optimistic.)
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Previously, by default we would install our python modules into
/usr/lib/python/xen, for example /usr/lib/python/xen/__init__.py.
Upstream python's standard install location (a) includes the Python
version number and (b) puts things in site-packages by default.
Our best conjecture for the reason for this was an attempt to make the
installs portable between different python versions. However, that
doesn't work because compiled python modules (.pyc), and C python
extensions corresponding to one version of python, are not compatible
across different versions of python.
This is why upstream include the version number.
site-packages is the standard location for locally-installed packages
and is automatically included on the python search path.
In this change, we abandon our own unusual python path setup:
* Invoke setup.py in an entirely standard manner. We pass
PREFIX and DESTDIR using the appropriate options provided by
setup.py for those purposes (adding them to setup.py calls
which were previously lacking them).
* Since the installation locations are now on the standard
python path, we no longer need to add anything to the path
in any of our python utilities. Therefore remove all that
code from every python script. (Many of these scripts
unconditionally added /usr/lib/python and /usr/lib64/python which
is wrong even in the old world.)
* There is no longer any special `Xen python path'. xen-python-path
is no longer needed. It is no longer called by anything in our
tree. However since out-of-tree callers may still invoke it, we
retain it. It now prints a fixed string referring to a directory
which does not to exist; callers (who use it to augment their
python path) will thus add a nonexistent directory to their python
path which is harmless.
* Remove various workarounds including use of setup.py --home
(which is intended for something completely different).
* Remove tests for the XEN_PYTHON_NATIVE_INSTALL build-time
environment variable. The new behaviour is the behaviour which we
should have had if this variable had been set. That is, it is now
as if this variable was always set but also bugs in the resulting
install have been fixed.
This should be a proper fix for the bug addressed by c/s 19515.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
I am modifying the xen- and xend-internal default policy so that
unlabeled domains can always start. A more restrictive security policy
can then be set on top of that policy.
Signed-off-by: Stefan Beger <stefanb@us.ibm.com>
This patch moves the directory of files where xend is writing policies
and resource labels into to /var/lib/xend/security/policies.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
This patch implements a (non Xen-API) legacy XML-RPC interface for the
ACM commands and funnels the calls into code introduced by the Xen-API
support for ACM security management. Since some of the functionality
has changed, also the xm applications have changed. In particular the
following old commands have been removed along with some tools the
have become obsolete now:
- loadpolicy (included in: setpolicy)
- makepolicy (included in: setpolicy)
- cfgbootpolicy (included in: setpolicy)
and the following commands been introduced:
- setpolicy
- getpolicy
- resetpolicy
All tools have been adapted to work in Xen-API and legacy XML-RPC
mode. Both modes support the same functionality.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Add support for removing/replacing a policy from the running
system. This operation is only successful if currently running VMs
would also be allowed to run under the new policy. Removing the
current policy means that the default policy is installed, which then
only has support for a single VM label and STE type (SystemManagement)
and is the same policy that the system starts up with when no policy
is chosen.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
This patch changes the XML schema of the ACM policy to require a
version and that every conflict set have a name. Every VM label must
have one Chinese Wall Type and every resource label one Simple Type
Enforcement Type. As a consequence of this some example policies
needed to be changed. Also not offering that many configuration
options for compiling xen anymore to make things simpler.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
- convert raw "install" command to use $(INSTALL)
- convert some $(INSTALL) to $(INSTALL_DATA) as appropriate
- modify the specific $(INSTALL) definitions to use -p.
Original patch by Ben Thomas <ben@virtualiron.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
Having both the Xen tree and the tools tree recurse into the foreign
headers directory causes headaches in parallel builds and when
building 32-bit tools + 64 bit Xen in the same tree.
Therefore we cause mk-symlinks to symlink in the foreign headers build
bits and generate a local version of the headers and checker tool.
Only libxc needs to do this since the other tools were actually
picking up the libxc version of the headers anyway so the mk-symlinks
calls can be removed from these components.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
and described in the user guide to demonstrate how to quickly create,
enforce, and test workload protection policies in Xen. The tool is aimed
to improve usability of sHype/ACM for Xen.It is included in a single
file to make it easy to try it out on different platforms (it inherits
the look and feel of the base platform). It is tested on Linux and
Windows. Please read the new user guide section about how to start and
use the tool (section 10.2).
Requirements: python (www.python.org), wxPython (www.wxpython.org or
try 'yum install wxPython').
Signed-off by: Reiner Sailer <sailer@us.ibm.com>
Subsequent patches will follow in the coming weeks that will enable
Xen ACM to control assignment of resources (e.g., block devices and
networking) to virtual machines based on resource labels and the
active security policy.
Signed-off-by: Bryan D. Payne <bdpayne@us.ibm.com>
Signed-off-by: Reiner Sailer <sailer@us.ibm.com>
introduced into security policies. It also fixes a minor problem related
to handling unsupported boot policies.
Signed-off by: Reiner Sailer <sailer@us.ibm.com>
* Move .PHONY directives next to targets,
this makes them a lot harder to miss
* Add missing .PHONY directives
* Remove nonexistent .PHONY directives
* Hopefully I didn'T miss anything...
Signed-Off-By: Horms <horms@verge.net.au>
creation/generation of the XML security policy files for the Xen ACM
security architecture. It is a python- based, web-based tool named
xensec_gen that allows users to create or modify XML policy files
through a browser. The resulting XML policy files can then be copied
or moved to the appropriate location in the /etc/xen/acm-security
directory structure in order to be translated into binary and used
within the Xen system.
Signed-off-by: Tom Lendacky <toml@us.ibm.com>
and installation. Particularly it does the following:
- the Makefile installs the ACM security-related tools
into /etc/xen/acm-security
- improves and cleans up some of the tools
- updates the documentation
Signed-off-by: Tom Lendacky <toml@us.ibm.com>
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
time (instead of at compile time). Allows a single xen.gz binary to
run under different security policy types, which simplifies
distributions considerably. To this end, we replace the current single
compile switch in Config.mk with the following two:
1. ACM_SECURITY (y/n) if "n", then the ACM is not compiled and no security
policies can be configured at boot time. If "y", then the ACM is compiled
and can be configured into any of the available policy types (null,
chwall, ste, chwall_ste) by specifying a valid boot policy .bin file in
the grub boot configuration.
2. ACM_DEFAULT_SECURITY_POLICY (null / chwall / ste / chwall_ste)
specifies the policy into which Xen defaults in the case that security is
enabled but no boot policy file is specified, or the specified policy file
is invalid (wrong version, magic, corrupted, ...)
While the type of the enabled policy (null, ste, ...) is decided once
during boot for the whole boot cycle, the policy instantiation can be
changed during operation as usual with the security tools.
Signed-off by: Tomas Lendacky <toml@us.ibm.com>
Signed-off by: Reiner Sailer <sailer@us.ibm.com>
1. adapts ACM hooks to the slightly changed event channel structure
2. introduces an ACM_GETDECISION command, which enables authorized
domains to retrieve policy decisions regarding the sharing of resources
(STE policy) from the Xen hypervisor
3. includes cleanup (warnings I found when applying analysis tools such
as beam or flawfinder to the ACM code)
The get_decision function is useful to enforce:
* the security policy on network traffic in the network backends in
domain 0; currently there is no enforcement in Dom0 and all packets flow
freely
* the security policy in block device backends to control which
domains can access which vdisk resources
I have added a small test program that shows how to use the get_decision
ACM interface call, it is in tools/security/get_decision.c and will be
compiled together with the policy tools. As usual, the ACM is unconfigured
until you switch on a security policy on in Config.mk.
Signed-off: Reiner Sailer <sailer@us.ibm.com>
* 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)
Signed-off-by Reiner Sailer <sailer@us.ibm.com>
Signed-off by Stefan Berger <stefanb@us.ibm.com>
* adds a C-based security policy translation tool to Xen (secpol_xml2bin)
and removes the current Java
security policy translator (Java dependencies). The C-based tool
integrates into the Xen source tree build
and install (using gnome libxml2 for XML parsing). See install.txt.
* introduces security labels and related tools. Users can now use
semantic-rich label names to put security-tags
on domains. See example.txt, policy.txt.
* moves the security configuration (currently ACM_USE_SECURITY_POLICY)
from xen/Rules.mk
into a separate top-level Security.mk file (it is needed by the
tools/security and xen/acm).
Both xen/acm and tools/security are built during the Xen build process
only if ACM_USE_SECURITY_POLICY
is not ACM_NULL_POLICY (which is the default setting).
Signed-off-by Reiner Sailer <sailer@us.ibm.com>
Signed-off by Stefan Berger <stefanb@us.ibm.com>
Signed-off by Ray Valdez <rvaldez@us.ibm.com>
