similar to: Security module (Flask) support should be disabled

Patch attached. Steve -- --- Makefile-orig 2006-09-04 14:37:18.000000000 +0100 +++ Makefile 2006-09-04 14:37:34.000000000 +0100 @@ -57,7 +57,7 @@ .PHONY: ioemu ioemuinstall ioemuclean ifndef XEN_NO_IOEMU ioemu ioemuinstall ioemuclean: - [ -f ioemu/config-host.h ] || \ + ( test -f ioemu/config-host.h ) || \ (cd ioemu; ./configure --prefix=usr) $(MAKE) -C

Package: xen-3.0 Version: 3.0.4-1-1 Severity: important From my pbuilder build log, using a chroot with packages mostly from sid except that gcc-defaults is from experimental: ... gcc -O2 -fomit-frame-pointer -m32 -march=i686 -DNDEBUG -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include

Hi, I have several machines using xen-hypervisor-3.2-1-i386 from etch-backports and they recently got upgraded to 20 or 24G RAM. I have seen talk of a limit of a 16G RAM with 32bit PAE Xen and indeed this is what I am seeing. I am guessing there is still no way to get the 32bit hypervisor to see more than 16G RAM, and I must go to 64bit. Can I boot a 64bit hypervisor and still keep the same

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-1 Severity: serious Tags: squeeze Hi there! Upgrading from Lenny to Squeeze left my box with xen-hypervisor-3.2-1-amd64 installed, and I had to "apt-get install xen-hypervisor-4.0-amd64" manually to have it installed after a dist-upgrade. This for sure, isn't the expected behavior. Also, after the dist-upgrade, I did: apt-get

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-1 Severity: grave Tags: squeeze upstream Some newer hardware components (it is unclear what exactly causes the issue) render xen-hyervisor unusable as it crashes immediately after boot for the Debian out-of-box configuration. This results in a system rebooting all over again if the hypervisor is choosen as default stanza to be booted by grub

These patches update the example FLASK policy shipped with Xen and enable its build if the required tools are present. The third patch requires rerunning autoconf to update tools/configure. [PATCH 1/3] flask/policy: sort dom0 accesses [PATCH 2/3] flask/policy: rework policy build system [PATCH 3/3] tools/flask: add FLASK policy to build

Adds support for assigning a label to domains, obtaining and setting the current enforcing mode, and loading a policy with xl command and libxl header when the Flask XSM is in use. Adheres to the changes made by the patch to remove exposure of libxenctrl/libxenstore headers via libxl.h. tools/libxl/libxl_flask.c | 71 ++++++++++++++++++ tools/libxl/Makefile | 2

Adds support for assigning a label to domains, obtaining and setting the current enforcing mode, and loading a policy with xl command when the Flask XSM is in use. libxl.c | 1 libxl.idl | 3 - xl.h | 3 + xl_cmdimpl.c | 171 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--- xl_cmdtable.c | 18 +++++- 5 files changed, 187 insertions(+), 9

I have just committed the patch below. Ian. # HG changeset patch # User Ian Jackson <Ian.Jackson@eu.citrix.com> # Date 1323712783 0 # Node ID 7ca56cca09ade16645fb4806be2c5b2b0bc3332b # Parent 7e90178b8bbfd2f78e8f4c6d593a2fb233350f41 flask: add tools/flask/utils/flask-label-pci to .hgignore This was apparently forgotten in 24353:448c48326d6b Signed-off-by: Ian Jackson

This patch set adds XSM security labels to useful debugging output locations, and fixes some assumptions that all interrupts behaved like GSI interrupts (which had useful non-dynamic IDs). It also cleans up the policy build process and adds an example of how to use the user field in the security context. Debug output: [PATCH 01/10] xsm: Add security labels to event-channel dump [PATCH 02/10] xsm:

Fix formatting of Flask AVC audit messages so that existing policy tools can parse them. After applying, ''xm dmesg | audit2allow'' yields the expected result. Signed-off-by: Stephen D. Smalley <sds@tycho.nsa.gov> Signed-off-by: George S. Coker, II <gscoker@alpha.ncsc.mil> --- xen/xsm/flask/avc.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)

Hi folks There are still some solutions missing in both trunk trees: - Patches from trunk (3.0) - udev symlink handling (both) A package is not allowed to put symlinks into /etc/udev/rules.d, it have to create it on the first installation and remove it on purge. - postint script needs to create /var/lib/xenstored (both) - initscript needs to create /var/run/xenstored (both) /var/run may be

Renato, Kristof, I confirm this is due to the latest Flask --- Flask-0.11 was released this weekend --- and for some unknown (to me at least) reason, although LNT's requirements.txt pins Flask to version 0.10.1, pip installs Flask-0.11. Forcing Flask to 0.10.1 gets the situation back to normal. Reading pip's documentation makes me think it's not able to resolve dependencies

Hello all, I am trying to get a xenstore/oxenstore (oxenstore is mirage based) stubdom to get to work on Xen 4.2.1. I know that I need to set XSM/FLASK rules and so I have compiled 4.2.1 with XSM and FLASK. I already talked with Daniel de Graaf (on the mailinglists) and Steven Maresca on IRC about this thing. Daniel already wrote a XSM/FLASK ruleset in this thread:

The FLASK security checks for resource ranges were not implemented correctly - only the permissions on the endpoints of a range were checked, instead of all items contained in the range. This would allow certain resources (I/O ports, I/O memory) to be used by domains in contravention to security policy. This also corrects a bug where adding overlapping resource ranges did not trigger an error.

Hello All, I'm trying to figure out why xen-utils-common 3.2 doesn't suport bridging on multiple interfaces. I've been digging around /etc/xen/scripts/network-bridges. And modified it so that during boot, when executed the script writes into /tmp/netbr file, but I commented out code that actually creates bridges. I discovered that this script is called three times during boot, I

I honestly do not know how to fix that --- I would otherwise I've committed a fix. I've been able to hack it locally exploiting the very same lit limitation then the one we're stumbling on (i.e it does not resolve dependency correctly and only pick-up the first constraint). You need to make sure the Flask constraint is seen first, even before using the requirements.txt so on the

This patch implements the Flask tools for the xen control plane (xm & xend). The patch also refactors the ACM toolchain so that a common security API (based on the existing ACM toolchain) is exported to xm and xend. To create a domain with the Flask module, add the following (for example) to a domain''s configuration file access_control =

Daniel, Tobias, Renato and myself have been looking a little bit at the potential underlying reason for why http://llvm.org/perf/ is instable, and have found some clues. I want to share them here to give people with more experience in the frameworks used by LNT (flask, sqlalchemy, wsgi, .) a chance to check if our reasoning below seems plausible. Daniel noticed the following backtrace in the

On 30 May 2016 at 12:25, Arnaud De Grandmaison <Arnaud.DeGrandmaison at arm.com> wrote: > I confirm this is due to the latest Flask --- Flask-0.11 was released this > weekend --- and for some unknown (to me at least) reason, although LNT's > requirements.txt pins Flask to version 0.10.1, pip installs Flask-0.11. > Forcing Flask to 0.10.1 gets the situation back to normal. Do