## # example.txt # # Author: # Reiner Sailer 08/15/2005 # 04/07/2006 update to using labels instead of ssidref # # # This file introduces into the tools to manage policies # and to label domains and resources. ## We will show how to install and use the example one of the client_v1 policies. Other policies work similarly. Feedback welcome! 1. Using xm tools to translate example.chwall_ste.client_v1 policy: =================================================================== #xm makepolicy example.chwall_ste.client_v1 By default, the tool looks in directory /etc/xen/acm-security/policies for a directory that matches the policy name (here:example/chwall_ste/client_v1-security_policy.xml) to find the policy files. The '-d' option can be used to override the default /etc/xen/acm-security/policies policy-root directory. The default policy directory structure under /etc/xen/acm-security (and the Xen security tool build directory - tools/security) looks like: policies |-- security_policy.xsd |-- example |-- chwall | |-- client_v1-security_policy.xml | |-- chwall_ste | |-- client_v1-security_policy.xml | |-- ste |-- client_v1-security_policy.xml The security_policy.xsd file contains the schema against which the policy files must validate during translation. The policy files, ending in -security_policy.xml, define the policies, the types known to the policies, and the label definitions that group types together and make them easier to use for users. After executing the above 'xm makepolicy' command, you will find 2 new files in the /etc/xen/acm-security/policies/example/chwall_ste sub-directory: client_v1.map ... this file includes the mapping of names from the xml files into their binary code representation. client_v1.bin ... this is the binary policy file, the result of parsing the xml files and using the mapping to create a binary version that can be loaded into the hypervisor. 2. Loading and activating the policy: ===================================== We assume that xen is already configured for security; please refer to install.txt for instructions. To activate the policy from the command line: # xm loadpolicy example.chwall_ste.client_v1 See install.txt for how to install a policy at boot time. This the recommended default. You can only load a policy if the currently enforced policy is "DEFAULT", a minimal startup policy, or if the currently enforced policy has the same name as the new one. Support for dynamic policy changes at run-time are a current working item. 3. Labeling domains: ==================== a) Labeling Domain0: The chwall_ste-security_label_template.xml file includes an attribute "bootstrap", which is set to the label name that will be assigned to Dom0 (this label will be mapped to ssidref 1/1, the default for Dom0). b) Labeling User Domains (domains started from dom0 using xm commands): We distinguish two kinds of labels: a) VM labels (for domains) and RES Labels (for resources). We focus here on VM labels. Resource labels will be supported later. To list all available domain labels of a policy, use: #xm labels example.chwall_ste.client_v1 To list all available labels including resource labels (their support is current work), use: #xm labels example.chwall_ste.client_v1 type=any The policy parameter is optional. The currently enforced hypervisor policy is used by default. If you would like to assign the dom_HomeBanking label to one of your user domains, look at the hypothetical domain configuration contained in /etc/xen/homebanking.xm: #------FOR HOME/ONLINE BANKING--------- kernel = "/boot/vmlinuz-2.6.16-xen" ramdisk="/boot/U1_ramdisk.img" memory = 164 name = "homebanking" vif=[''] dhcp = "dhcp" #------------------------- Now we label this domain (policy name is optional, see above): # xm addlabel homebanking.xm dom_HomeBanking example.chwall_ste.client_v1 The domain configuration should look now like: # cat homebanking.xm #------FOR HOME/ONLINE BANKING--------- kernel = "/boot/vmlinuz-2.6.16-xen" ramdisk="/boot/U1_ramdisk.img" memory = 164 name = "homebanking" vif=[''] dhcp = "dhcp" access_control = ['policy=example.chwall_ste.client_v1, label=dom_HomeBanking'] You can see the access_control line that was added to the configuration. This label will be translated into a local ssidref when a domain is created or resumed (also after migration and live-migration). The ssidref is a local security reference that is used inside the hypervisor instead of the security label for efficiency reasons. Since the same label can be mapped onto different ssidrefs in different policy translations (e.g., if the position of the label definition is changed in the policy file) or on different systems, the ssidref is re-calculated from the label each time a domain is instantiated or re-instantiated. Currently, the labels are not held in the hypervisor but only in .map files in the /etc/xen/acm-security/policies subdirectories. Only ssidrefs are known inside the hypervisr. This of course can change in the future. 4. Starting a labeled domain ============================ Now, start the domain: #xm create homebanking.xm Using config file "homebanking.xm". Started domain fun [root@941e-4 VMconfigs]# xm list --label Name ID Mem(MiB) VCPUs State Time(s) Label fun 1 64 1 -b---- 5.9 dom_HomeBanking Domain-0 0 1954 1 r----- 1321.4 dom_SystemManagement If you label another domain configuration as dom_Fun and if you try to start it afterwards, this create will fail. Why? -- Because the running 'homebanking' domain has the chinese wall type "cw_Sensitive". The new domain 'fun' has the chinese wall label "cw_Distrusted". These domains are not allowed to run simultaneously on the same system because of the defined conflict set cw_Sensitive cw_Distrusted (in client_v1-security_policy.xml), which says that only one of the types cw_Sensitive and cw_Distrusted can run at a time. If you save or shutdown the 'homebanking' domain, you will be able to start the 'fun' domain. You can look into the Xen log to see if a domain was denied to start because of the access control framework with the command 'xm dmesg'. It is important (and usually non-trivial) to define the labels in a way that the semantics of the labels are enforced and supported by the types and the conflict sets. Usually, a workload abstraction seems helpful on the hypervisor level. Note: While the chinese wall policy enforcement is complete, the type enforcement is currently enforced inside the Xen hypervisor only. Therefore, only point-to-point sharing with regard to the type enforcement is currently controlled. Enforcing the STE policy while sharing virtual resources is ongoing work and assumed to be complete by year end as well as enforcing the STE policy for network traffic routed through dom0. 5. Adding your own policies =========================== Writing your own policy (e.g. "mypolicy.chwall.test") requires the policy definition (types etc.) and the label definitions. Any policy name must have chwall, ste, or chwall_ste in its name. This is used by the configuration tool to identify existing binary policy entries in the boot configuration file (menu.lst, grub.con). This part should, of course, be consistent with policy type that is defined. First, you create /etc/xen/acm-security/policies/mypolicy/chwall/test-security_policy.xml. You need to keep to the schema as defined in /etc/xen/acm-security/security_policy.xsd since the translation tools are written against this schema. You can hand-edit the xml files to create your policy or you can use the xensec_gen utility. 6. Generating policy files using xensec_gen: ============================================ The xensec_gen utility starts a web-server that can be used to generate the XML policy files needed to create a policy. By default, xensec_gen runs as a daemon and listens on port 7777 for HTTP requests. The xensec_gen command supports command line options to change the listen port, run in the foreground, and a few others. Type 'xensec_gen -h' to see the full list of options available. Once the xensec_gen utility is running, point a browser at the host and port on which the utility is running (e.g. http://localhost:7777/). You will be presented with a web page that allows you to create or modify the XML policy file: - The Security Policy types section allows you to create or modify the policy types and conflict set definitions - The Security Policy Labeling section allows you to create or modify a label definitions The policy generation tool allows you to modify an existing policy definition or create a new policy definition file. To modify an existing policy definition, enter the full path to the existing file (the "Browse" button can be used to aid in this) in the Policy File entry field. To create a new policy definition file leave the Policy File entry field blank. At this point click the "Create" button to begin modifying or creating your policy definition. Security Policy Types Section ----------------------------- You will then be presented with a web page. The upper part of it will allow you to create either Simple Type Enforcement types or Chinese Wall types or both, as well as Chinese Wall conflict type sets. As an example: - To add a Simple Type Enforcement type: - Enter the name of a new type under the Simple Type Enforcement Types section in the entry field above the "New" button. - Click the "New" button and the type will be added to the list of defined Simple Type Enforcement types. - To remove a Simple Type Enforcement type: - Click on the type to be removed in the list of defined Simple Type Enforcement types. - Click the "Delete" button to remove the type. Follow the same process to add Chinese Wall types. If you define Chinese Wall types you need to define at least one Chinese Wall Conflict Set. The Chinese Wall Conflict Set will allow you to add Chinese Wall types from the list of defined Chinese Wall types. Security Policy Labeling: ------------------------- The security policy label section of the web page allows you to create labels for classes of virtual machines. The input policy type definitions on the upper part of the web page will provide the available types (Simple Type Enforcement and/or Chinese Wall) that c
#
# Copyright (C) 2006-2013 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
#

INPUT_MODULES_MENU:=Input modules

define KernelPackage/hid
  SUBMENU:=$(INPUT_MODULES_MENU)
  TITLE:=HID Devices
  KCONFIG:=CONFIG_HID CONFIG_HIDRAW=y
  FILES:=$(LINUX_DIR)/drivers/hid/hid.ko
  AUTOLOAD:=$(call AutoLoad,61,hid)
  $(call AddDepends/input,+kmod-input-evdev)
endef

define KernelPackage/hid/description
 Kernel modules for HID devices
endef

$(eval $(call KernelPackage,hid))

define KernelPackage/hid-generic
  SUBMENU:=$(INPUT_MODULES_MENU)
  TITLE:=Generic HID device support
  KCONFIG:=CONFIG_HID_GENERIC
  FILES:=$(LINUX_DIR)/drivers/hid/hid-generic.ko
  AUTOLOAD:=$(call AutoLoad,62,hid-generic)
  $(call AddDepends/hid)
endef

define KernelPackage/hid/description
  Kernel modules for generic HID device (e.g. keyboards and mice) support
endef

$(eval $(call KernelPackage,hid-generic))

define KernelPackage/input-core
  SUBMENU:=$(INPUT_MODULES_MENU)
  TITLE:=Input device core
  KCONFIG:=CONFIG_INPUT
  FILES:=$(LINUX_DIR)/drivers/input/input-core.ko
  AUTOLOAD:=$(call AutoLoad,19,input-core,1)
endef

define KernelPackage/input-core/description
 Kernel modules for support of input device
endef

$(eval $(call KernelPackage,input-core))


define KernelPackage/input-evdev
  SUBMENU:=$(INPUT_MODULES_MENU)
  TITLE:=Input event device
  KCONFIG:=CONFIG_INPUT_EVDEV
  FILES:=$(LINUX_DIR)/drivers/input/evdev.ko
  AUTOLOAD:=$(call AutoLoad,60,evdev)
  $(call AddDepends/input)
endef

define KernelPackage/input-evdev/description
 Kernel modules for support of input device events
endef

$(eval $(call KernelPackage,input-evdev))


define KernelPackage/input-gpio-buttons
  SUBMENU:=$(INPUT_MODULES_MENU)
  TITLE:=Polled GPIO buttons input device
  DEPENDS:=@GPIO_SUPPORT +kmod-input-polldev
  KCONFIG:= \
	CONFIG_INPUT_GPIO_BUTTONS \
	CONFIG_INPUT_MISC=y
  FILES:=$(LINUX_DIR)/drivers/input/misc/gpio_buttons.ko
  AUTOLOAD:=$(call AutoLoad,62,gpio_buttons,1)
endef

define KernelPackage/input-gpio-buttons/description
 Kernel module for support polled GPIO buttons input device
endef

$(eval $(call KernelPackage,input-gpio-buttons))


define KernelPackage/input-gpio-keys
  SUBMENU:=$(INPUT_MODULES_MENU)
  TITLE:=GPIO key support
  DEPENDS:= @GPIO_SUPPORT
  KCONFIG:= \
	CONFIG_KEYBOARD_GPIO \
	CONFIG_INPUT_KEYBOARD=y
  FILES:=$(LINUX_DIR)/drivers/input/keyboard/gpio_keys.ko
  AUTOLOAD:=$(call AutoLoad,60,gpio_keys)
  $(call AddDepends/input)
endef

define KernelPackage/input-gpio-keys/description
 This driver implements support for buttons connected
 to GPIO pins of various CPUs (and some other chips).
endef

$(eval $(call KernelPackage,input-gpio-keys))


define KernelPackage/input-gpio-keys-polled
  SUBMENU:=$(INPUT_MODULES_MENU)
  TITLE:=Polled GPIO key support
  DEPENDS:=@GPIO_SUPPORT +kmod-input-polldev
  KCONFIG:= \
	CONFIG_KEYBOARD_GPIO_POLLED \
	CONFIG_INPUT_KEYBOARD=y
  FILES:=$(LINUX_DIR)/drivers/input/keyboard/gpio_keys_polled.ko
  AUTOLOAD:=$(call AutoLoad,62,gpio_keys_polled,1)
  $(call AddDepends/input)
endef

define KernelPackage/input-gpio-keys-polled/description
 Kernel module for support polled GPIO keys input device
endef

$(eval $(call KernelPackage,input-gpio-keys-polled))


define KernelPackage/input-gpio-encoder
  SUBMENU:=$(INPUT_MODULES_MENU)
  TITLE:=GPIO rotay encoder
  KCONFIG:=CONFIG_INPUT_GPIO_ROTARY_ENCODER
  FILES:=$(LINUX_DIR)/drivers/input/misc/rotary_encoder.ko
  AUTOLOAD:=$(call AutoLoad,62,rotary_encoder)
  $(call AddDepends/input,@GPIO_SUPPORT)
endef

define KernelPackage/gpio-encoder/description
 Kernel module to use rotary encoders connected to GPIO pins
endef

$(eval $(call KernelPackage,input-gpio-encoder))


define KernelPackage/input-joydev
  SUBMENU:=$(INPUT_MODULES_MENU)
  TITLE:=Joystick device support
  KCONFIG:=CONFIG_INPUT_JOYDEV
  FILES:=$(LINUX_DIR)/drivers/input/joydev.ko
  AUTOLOAD:=$(call AutoLoad,62,joydev)
  $(call AddDepends/input)
endef

define KernelPackage/input-joydev/description
  Kernel module for joystick support
endef

$(eval $(call KernelPackage,input-joydev))


define KernelPackage/input-polldev
  SUBMENU:=$(INPUT_MODULES_MENU)
  TITLE:=Polled Input device support
  KCONFIG:=CONFIG_INPUT_POLLDEV
  FILES:=$(LINUX_DIR)/drivers/input/input-polldev.ko
  AUTOLOAD:=$(call AutoLoad,20,input-polldev,1)
  $(call AddDepends/input)
endef

define KernelPackage/input-polldev/description
 Kernel module for support of polled input devices
endef

$(eval $(call KernelPackage,input-polldev))


define KernelPackage/input-matrixkmap
   SUBMENU:=$(INPUT_MODULES_MENU)
   TITLE:=Input matrix devices support
   KCONFIG:=CONFIG_INPUT_MATRIXKMAP
   DEPENDS:=@!LINUX_3_3
   FILES:=$(LINUX_DIR)/drivers/input/matrix-keymap.ko
   AUTOLOAD:=$(call AutoLoad,20,matrix-keymap)
   $(call AddDepends/input)
endef

define KernelPackage/input-matrix/description
  Kernel module support for input matrix devices
endef

$(eval $(call KernelPackage,input-matrixkmap))


define KernelPackage/acpi-button
  SUBMENU:=$(INPUT_MODULES_MENU)
  TITLE:=ACPI Button Support
  DEPENDS:=@(TARGET_x86_generic||TARGET_x86_kvm_guest||TARGET_x86_xen_domu) +kmod-input-evdev
  KCONFIG:=CONFIG_ACPI_BUTTON
  FILES:=$(LINUX_DIR)/drivers/acpi/button.ko
  AUTOLOAD:=$(call AutoLoad,06,button)
endef

define KernelPackage/acpi-button/description
 Kernel module for ACPI Button support
endef

$(eval $(call KernelPackage,acpi-button))
generated by cgit v1.2.3 (git 2.25.1) at 2026-02-04 09:21:33 +0000