Re: [SELinux-notebook PATCH] adds CIL policy with makefile

[Dominick Grift <dominick.grift@defensec.nl>]

On 7/16/20 9:05 PM, Richard Haines wrote:
> On Thu, 2020-07-16 at 12:08 +0200, Dominick Grift wrote:
>> This example CIL policy takes a different approach:
>>
>> 1. Leverages CIL
>> 2. Installs using semodule to make it tunable at runtime (but you can
>> obviously also use secilc to build a monolithic version and deploy
>> that)
>> 3. Makes few assumptions about variables
>> 4. Leverages handleunknown allow and declares least required access
>> vectors so that you can pick and choose which access vectors you want
>> to use and ignore the remainder
>> 5. Leverages unlabeled and file ISID and makes no assumptions about
>> any volatile filesystems you may or may not use
>> 6. As small and simple as reasonably possible, heavily documented
>> 7. Modern, Requires SELinux 3.1
> 
> 
> I've no idea what x-server you use, however I've now tested this policy
> on two Fedora 32 X-Windows types Xwayland and Xorg, these are the
> results:

Thanks

I do not use Xserver and Xwayland anymore, I use native wayland only
as gtk3 and QT5 support native wayland, and i do not use a proprietory
nvidia blob or use play steam games.

> 
> Xwayland now works as the boolean disables the x-server. As I don't
> think Xwayland was built with SELinux support, this is the only option.

If I understand it correctly you are suggesting that with the following
in XSERVER_XWAYLAND.md I should cover all scenarios?

echo "(boolean xserver_object_manager false)" > noxace.cil && semodule
-i noxace.cil

> 
> To configure Xorg I modified /etc/gdm/custom.conf as follows:
> 
> [daemon]
> WaylandEnable=false
> DefaultSession=gnome-xorg.desktop
> 
> Xorg with your current config hangs on boot when starting GDM with this
> in the log:
> 
> gdm-x-session[990]: SELinux: a property label lookup failed!
> gdm-x-session[990]: Fatal server error:
> gdm-x-session[990]: (EE) SELinux: Failed to set label property on
> window!
> 

I am not sure but I think that option may be for native wayland, and not
xwayland? Maybe it ran xwayland (i may be wrong)?

I use to run x-server with: `startx -- /usr/bin/awesome` mostly

> There are two possible fixes for this:
> 
> 1) If you want Xorg to run with SELinux enabled, the x_contexts file
> must contain the following:
> 
> client * sys.id:sys.role:sys.isid
> property * sys.id:sys.role:sys.isid
> extension * sys.id:sys.role:sys.isid
> selection * sys.id:sys.role:sys.isid
> event * sys.id:sys.role:sys.isid

I prefer not to go this route

> 
> 2) If you want Xorg to run with SELinux disabled there must be either a
> file /etc/X11/xorg.conf.d/90-selinux.conf that contains:
> 
> Section "Module"
> SubSection "extmod"
> Option "SELinux mode disabled"
> EndSubSection
> EndSection

In my (old) setup, i believe, i did not strictly need this as xserver
would try to read /etc/selinux/cil-policy/contexts/x_contexts and if it
cannot parse its content it will disable XACE in my experience, but read
below:

> 
> Or add the (boolean xserver_object_manager false) to policy.
> Note with these the x_contexts file contents are not relevant.

Okay, then this is my preferred route. ie just add a XSERVER_XWAYLAND.md
with:

If you are still using Xserver or Xwayland then the following may be
required:

echo "(boolean xserver_object_manager false)" > myxwaylandhack.cil &&
semodule -i myxwaylandhack.cil

Sound okay?

No point in trying to support XACE as its pre-DRI3, and DRI3 changes
things. There is no easy way to disable DRI3 (unless you use QXL or vesa)

> 
> You can then boot the system in enforcing mode using your policy with
> any of the above options.
> 
> I've added two minor comments in the code below.
> 
> 
>>
>> Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
>> ---
>>  src/cil_overview.md                           |  11 +
>>  src/notebook-examples/README.md               |   2 +
>>  src/notebook-examples/cil-policy/Makefile     |  36 ++
>>  src/notebook-examples/cil-policy/README.md    |  71 +++
>>  src/notebook-examples/cil-policy/XWAYLAND.md  |   7 +
>>  .../cil-policy/cil-policy.cil                 | 445
>> ++++++++++++++++++
>>  6 files changed, 572 insertions(+)
>>  create mode 100644 src/notebook-examples/cil-policy/Makefile
>>  create mode 100644 src/notebook-examples/cil-policy/README.md
>>  create mode 100644 src/notebook-examples/cil-policy/XWAYLAND.md
>>  create mode 100644 src/notebook-examples/cil-policy/cil-policy.cil
>>
>> diff --git a/src/cil_overview.md b/src/cil_overview.md
>> index a05aad5..1403666 100644
>> --- a/src/cil_overview.md
>> +++ b/src/cil_overview.md
>> @@ -135,6 +135,17 @@ Usage: build-sepolicy [-k] [-M] [-c|-p|-s] -d
>> flask_directory -o output_file
>>  -d    Directory containing the initial_sids, security_classes and
>> access_vectors Flask files.
>>  -o    The output file that will contain the policy source or header
>> file.
>>  ```
>> +There is another CIL policy in the notebook examples called
>> +"cil-policy" that takes a slightly different approach where the goal
>> +is to keep the policy as simple as possible. It requires `semodule`,
>> +Linux 5.7, SELinux 3.1 and can be installed by executing
>> +`make install`. It leverages some modern SELinux features, most
>> +notably where the requirement for ordered security classes is
>> lifted.
>> +With this you are no longer expected to be aware of all the access
>> +vectors managed by Linux in order to align your security class
>> +declarations with the order in which they are declared in the
>> kernel.
>> +A module store is created by `semodule` to give easy access to the
>> +source and that allows for full control over the policy.
>>  
>>  <br>
>>  
>> diff --git a/src/notebook-examples/README.md b/src/notebook-
>> examples/README.md
>> index 488ec6e..1bb611b 100644
>> --- a/src/notebook-examples/README.md
>> +++ b/src/notebook-examples/README.md
>> @@ -2,6 +2,8 @@
>>  
>>  This area contains the following directories:
>>  
>> +***cil-policy*** - Contains info to build and install simple CIL
>> policy.
>> +
>>  ***network*** - Contains CIPSO, CALIPSO and IPSEC examples.
>>  
>>  ***selinux-policy*** - Contains info to build simple kernel and CIL
>> policy.
>> diff --git a/src/notebook-examples/cil-policy/Makefile
>> b/src/notebook-examples/cil-policy/Makefile
>> new file mode 100644
>> index 0000000..7e6e7cb
>> --- /dev/null
>> +++ b/src/notebook-examples/cil-policy/Makefile
>> @@ -0,0 +1,36 @@
>> +# -*- Mode: makefile; indent-tabs-mode: t -*-
>> +# SPDX-License-Identifier: Unlicense
>> +
>> +.PHONY: install
>> +
>> +all: install
>> +
>> +install:
>> +	mkdir -p /etc/selinux/cil-
>> policy/{contexts,logins,policy,contexts/files,contexts/users}
>> +	touch /etc/selinux/cil-policy/contexts/customizable_types
>> +	touch /etc/selinux/cil-policy/contexts/file_contexts.subs_dist
>> +	echo -e """<!DOCTYPE busconfig PUBLIC \
>> +\"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN\" \
>> +\n\"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd\"> \
>> +\n<busconfig> \
>> +\n<selinux> \
>> +\n</selinux> \
>> +\n</busconfig>""" > /etc/selinux/cil-policy/contexts/dbus_contexts
>> +	echo "sys.role:sys.isid sys.role:sys.isid" > /etc/selinux/cil-
>> policy/contexts/default_contexts
>> +	echo "sys.role:sys.isid" > /etc/selinux/cil-
>> policy/contexts/default_type
>> +	echo "sys.role:sys.isid" > /etc/selinux/cil-
>> policy/contexts/failsafe_context
>> +	echo -e """cdrom sys.id:sys.role:sys.isid \
>> +\nfloppy sys.id:sys.role:sys.isid \
>> +\ndisk sys.id:sys.role:sys.isid""" > /etc/selinux/cil-
>> policy/contexts/files/media
>> +	echo "privsep_preauth=sys.isid" > /etc/selinux/cil-
>> policy/contexts/openssh_contexts
>> +	echo "sys.id:sys.role:sys.isid" > /etc/selinux/cil-
>> policy/contexts/removable_context
>> +	echo "sys.isid" > /etc/selinux/cil-
>> policy/contexts/securetty_types
>> +	echo "sys.id:sys.role:sys.isid" > /etc/selinux/cil-
>> policy/contexts/virtual_domain_context
>> +	echo -e """sys.id:sys.role:sys.isid \
>> +\nsys.id:sys.role:sys.isid""" > /etc/selinux/cil-
>> policy/contexts/virtual_image_context
>> +	echo -e """Section \"Module\" \
>> +\nSubSection \"extmod\" \
>> +\nOption \"SELinux mode disabled\" \
>> +\nEndSubSection \
>> +\nEndSection""" > /etc/selinux/cil-policy/contexts/x_contexts
> 
> See above comments on the x_contexts file.
> 
>> +	semodule --priority=100 -N -s cil-policy -i cil-policy.cil
>> diff --git a/src/notebook-examples/cil-policy/README.md
>> b/src/notebook-examples/cil-policy/README.md
>> new file mode 100644
>> index 0000000..a3c9b56
>> --- /dev/null
>> +++ b/src/notebook-examples/cil-policy/README.md
>> @@ -0,0 +1,71 @@
>> +# CIL policy from scratch that is mutable at runtime
>> +
>> +This example demonstrates an alternative approach to implementing a
>> +first iteration of a CIL policy from scratch. The main idea is to
>> +create a policy that is as small as reasonably possible, and to
>> +install that by using `semodule`. This will provide you with bare
>> +miminums to get you started in enforcing mode.
>> +
>> +To achieve this there are two key features leveraged. The
>> +`handleunknown` statement, the `unlabeled` and `file` initial
>> +security identifiers. By allowing unknown access vectors by default
>> we
>> +can reduce the amount of classes and access vector permission
>> +declarations needed to get started. This was only recently made
>> +possible by lifting the requirement to order classes. Requiring
>> +classes to be ordered implies that the classes are declared, thus it
>> +requires that you know what classes are managed by Linux. Now we
>> only
>> +have to be aware of, and declare, a small number of classes and a
>> few
>> +permissions to get started. All the remaining unknown access vectors
>> +will be reported to us by SELinux via the kernel ring buffer, it is
>> +just a matter of looking at `dmesg` to see which access vectors are
>> +managed by Linux but are unknown to the policy, and then to address
>> +those in the policy as we go along. You can generally pick and
>> choose
>> +which access vectors you want to use to achieve your access control
>> +requirements and you can imply ignore any access vectors that you do
>> +not need.
>> +
>> +The `unlabeled` initial security identifier is used to associate a
>> +specified context with entities that have their existing context
>> +invalidated. The `file` initial security identifier is used to
>> +associate a context with objects that have no labels. This
>> +functionality can be taken advantage of to reduce the work needed to
>> +get a working first iteration of the policy that we can then build
>> +upon. Initial security identifier associated contexts are associated
>> +with entities in memory. This means that effectively we do not have
>> +to worry about persistent labels in our first iteration. We can
>> +address labeling requirements as a first next step to get going.
>> +
>> +By using `semodule` we create a module store that we can use to
>> +manage policy at runtime and all the source policy is
>> +readily accessible through the store. Some changes might require
>> +reboot in some scenarios. You can effectively switch to cil-policy
>> at
>> +runtime in enforcing mode if your system was already enforcing a
>> +policy before. Otherwise you might have to reboot to load initial
>> +policy.
>> +
>> +This repository comes with a heavily commented CIL module and a make
>> +file that addresses installation. The make file does make some
>> +assumptions that are relatively safe but if something breaks, you
>> get
>> +to keep the pieces. This example requires Linux 5.7 and SELinux 3.1
>> +because it omits initial sid context specifications for unused
>> +initial security identifiers.
>> +
>> +## Switching to cil-policy from a another policy
>> +
>> +1. make install
>> +2. sed -i 's/SELINUXTYPE=.*/SELINUXTYPE=cil-policy/'
>> /etc/selinux/config
>> +3. semodule -B
>> +
>> +Your first step to actually leverage cil-policy will likely be to
>> +enable labeling support for your non-volatile filesystems, and to
>> +apply labels according to the file context specifications defined in
>> +the policy.
>> +
>> +For example if you use `ext4` filesystems:
>> +
>> +1. echo '(fsuse xattr "ext4" (sys.id sys.role sys.isid ((s0)(s0))))'
>>> myfs.cil
>> +2. semodule -i myfs.cil
>> +3. fixfiles onboot && reboot
>> +
>> +Use your favorite text editor to write policy in [Common
>> Intermediate Language](
>> https://github.com/SELinuxProject/selinux/blob/master/secilc/docs/README.md
>> ),
>> +manage it with `semodule`, and analyze it with `setools`.
>> diff --git a/src/notebook-examples/cil-policy/XWAYLAND.md
>> b/src/notebook-examples/cil-policy/XWAYLAND.md
>> new file mode 100644
>> index 0000000..322576d
>> --- /dev/null
>> +++ b/src/notebook-examples/cil-policy/XWAYLAND.md
>> @@ -0,0 +1,7 @@
>> +# Xwayland considerations
>> +
>> +In the scenario where you are still using Xwayland there are some
>> +special considerations:
>> +
>> +1. cp /etc/selinux/cil-policy/contexts/x_contexts
>> /etc/X11/xorg.conf.d/90-selinux.conf
> 
> The 90-selinux.conf file is not required for Xwayland as it never even
> tries to read it. It would be required for Xorg if you want to disable
> XSELinux (or use the boolean below).
> 
>> +2. echo "(boolean xserver_object_manager false)" >
>> myxwaylandhack.cil && semodule -i myxwaylandhack.cil
>> diff --git a/src/notebook-examples/cil-policy/cil-policy.cil
>> b/src/notebook-examples/cil-policy/cil-policy.cil
>> new file mode 100644
>> index 0000000..c36eb4b
>> --- /dev/null
>> +++ b/src/notebook-examples/cil-policy/cil-policy.cil
>> @@ -0,0 +1,445 @@
>> +;; -*- mode: CIL; fill-column: 79; indent-tabs-mode: nil; -*-
>> +;; SPDX-License-Identifier: Unlicense
>> +
>> +;;
>> +;; Policy configuration:
>> +;;
>> +;; By allowing unknown access vectors we can start with a reduced
>> number
>> +;; of declared classes and access vectors. Use `dmesg | grep -i
>> selinux` to
>> +;; see which kernel classes and access vectors should be addressed
>> in the
>> +;; policy as you go along.
>> +;;
>> +
>> +(handleunknown allow)
>> +
>> +;;
>> +;; Policy configuration:
>> +;;
>> +;; We'll disable the MLS security model support for simplicity, but
>> CIL still
>> +;; requires us to write our policy with minimal MLS-awareness.
>> Remember, we can
>> +;; alway's add full or partial MLS support later. This is just to
>> get started.
>> +;;
>> +
>> +(mls false)
>> +
>> +;;
>> +;; Access vector declarations and (un)ordering:
>> +;;
>> +;; SELinux requires that the process security class, transition and
>> +;; dyntransition access vector permissions are declared. CIL
>> requires at least
>> +;; one declared access vector and avc rule as well so this is a good
>> starting
>> +;; point. All security classes can be "unordered" with Linux
>> 5.7/SELinux 3.1.
>> +;;
>> +
>> +(class process (dyntransition transition))
>> +(classorder (unordered process))
>> +
>> +;;
>> +;; Access vector declarations and (un)ordering:
>> +;;
>> +;; To be able to associate roles with files, we need defaultrole
>> rules that
>> +;; require file classes to be declared. For now we'll omit their
>> associated
>> +;; access vector permissions for simplicity (get them from `dmesg |
>> grep -i selinux`)
>> +;;
>> +
>> +(class blk_file ())
>> +(classorder (unordered blk_file))
>> +
>> +(class chr_file ())
>> +(classorder (unordered chr_file))
>> +
>> +(class dir ())
>> +(classorder (unordered dir))
>> +
>> +(class fifo_file ())
>> +(classorder (unordered fifo_file))
>> +
>> +(class file ())
>> +(classorder (unordered file))
>> +
>> +(class lnk_file ())
>> +(classorder (unordered lnk_file))
>> +
>> +(class sock_file ())
>> +(classorder (unordered sock_file))
>> +
>> +;;
>> +;; Initial security identifier declarations:
>> +;;
>> +;; The kernel isid is used to associate a specified context with
>> processes
>> +;; that were initialized before SELinux was initialized (mainly
>> kernel threads).
>> +;;
>> +
>> +(sid kernel)
>> +
>> +;;
>> +;; Initial security identifier declarations:
>> +;;
>> +;; The security isid is used to associate a specified context with
>> "fixed"
>> +;; SELinux "objects" used to enforce access control on SELinux
>> operations
>> +;; (for example setenforce, setbool etc).
>> +;;
>> +
>> +(sid security)
>> +
>> +;;
>> +;; Initial security identifier declarations:
>> +;;
>> +;; The port isid is used to associate a specified context with
>> "fixed"
>> +;; network port "objects" used to enforce access control on network
>> +;; operations (for example name_connect, name_bind etc).
>> +;;
>> +
>> +(sid port)
>> +
>> +;;
>> +;; Initial security identifier declarations:
>> +;;
>> +;; The netif isid is used to associate a specified context with
>> "fixed"
>> +;; network interface "objects" used to enforce access control on
>> network
>> +;; operations (for example egress, ingress etc).
>> +;;
>> +
>> +(sid netif)
>> +
>> +;;
>> +;; Initial security identifier declarations:
>> +;;
>> +;; The netmsg isid is used to associate a specified context with
>> "fixed"
>> +;; network peer "objects" used to enforce access control on network
>> +;; operations (for example recv).
>> +;;
>> +
>> +(sid netmsg)
>> +
>> +;;
>> +;; Initial security identifier declarations:
>> +;;
>> +;; The node isid is used to associate a specified context with
>> "fixed"
>> +;; network node "objects" used to enforce access control on network
>> +;; operations (for example node_bind etc).
>> +;;
>> +
>> +(sid node)
>> +
>> +;;
>> +;; Initial security identifier declarations:
>> +;;
>> +;; The devnull isid is used to associate a specified context with
>> "fixed"
>> +;; null device "objects" used to enforce access control on file
>> +;; operations (for example read, write etc).
>> +;;
>> +
>> +(sid devnull)
>> +
>> +;;
>> +;; Initial security identifier declarations:
>> +;;
>> +;; The file isid is used to associate a specified context with
>> objects
>> +;; that have no label (for example formatted filesystems that are
>> not labeled).
>> +;;
>> +
>> +(sid file)
>> +
>> +;;
>> +;; Initial security identifier declarations:
>> +;;
>> +;; The unlabeled isid is used to associate a specified context with
>> entities
>> +;; that had their security context invalidated (mainly due to
>> modifications to
>> +;; policy at runtime).
>> +;;
>> +
>> +(sid unlabeled)
>> +
>> +;;
>> +;; Initial security identifier declarations:
>> +;;
>> +;; The following initial security identifiers are unused but are
>> required
>> +;; for "sid ordering"
>> +;;
>> +
>> +(sid any_socket)
>> +(sid file_labels)
>> +(sid fs)
>> +(sid icmp_socket)
>> +(sid igmp_packet)
>> +(sid init)
>> +(sid kmod)
>> +(sid policy)
>> +(sid scmp_packet)
>> +(sid sysctl)
>> +(sid sysctl_dev)
>> +(sid sysctl_fs)
>> +(sid sysctl_kernel)
>> +(sid sysctl_modprobe)
>> +(sid sysctl_net)
>> +(sid sysctl_net_unix)
>> +(sid sysctl_vm)
>> +(sid tcp_socket)
>> +
>> +;;
>> +;; Initial security identifier ordering:
>> +;;
>> +;; Even though most initial security identifiers we declared are no
>> longer in
>> +;; use, we still have to retain a very specific order to stay
>> compatible with
>> +;; the kernel. This is certainly one of those things that make
>> policy writing
>> +;; seem like some sort of black magic and hopefully some day we can
>> lift the
>> +;; requirement to order initial sids in a specific way.
>> +;;
>> +
>> +(sidorder
>> + (kernel security unlabeled fs file file_labels init any_socket port
>> +         netif netmsg node igmp_packet icmp_socket tcp_socket
>> sysctl_modprobe
>> +         sysctl sysctl_fs sysctl_kernel sysctl_net sysctl_net_unix
>> +         sysctl_vm sysctl_dev kmod policy scmp_packet devnull))
>> +
>> +;;
>> +;; Security identifier declarations
>> +;;
>> +;; Security contexts are identifiers that are combinations of
>> security
>> +;; attribute and security identifier key value pairs corresponding
>> to security
>> +;; models.
>> +;;
>> +;; The s0 security identifier is associated with sensitivity
>> attribute in a
>> +;; security context used to enforce confidentiality with the Multi
>> level
>> +;; security model. (we only declare one sensitivity for simplicity
>> and to
>> +;; satisfy CIL.
>> +;;
>> +
>> +(sensitivity s0)
>> +
>> +;;
>> +;; Security identifier declarations
>> +;;
>> +;; Security contexts are identifiers that are combinations of
>> security
>> +;; attribute and security identifier key value pairs corresponding
>> to security
>> +;; models.
>> +;;
>> +;; The c0 security identifier is associated with category attribute
>> in a
>> +;; security context used to enforce compartmentalization with the
>> Multi level
>> +;; security model. (we only declare one compartment for simplicity
>> and to
>> +;; satisfy CIL.
>> +;;
>> +
>> +(category c0)
>> +
>> +;;
>> +;; Security identifier declarations
>> +;;
>> +;; Security contexts are identifiers that are combinations of
>> security
>> +;; attribute and security identifier key value pairs corresponding
>> to security
>> +;; models.
>> +;;
>> +;; The sys.id security identifier is associated with user attribute
>> in a
>> +;; security context used to associate with Linux DAC and role and
>> level security
>> +;; identifiers with the Identity-based access control security
>> model.
>> +;;
>> +;; Note that we leverage a simple CIL "sys" "container" here
>> +;;
>> +
>> +(block sys (user id))
>> +
>> +;;
>> +;; Security identifier declarations
>> +;;
>> +;; Security contexts are identifiers that are combinations of
>> security
>> +;; attribute and security identifier key value pairs corresponding
>> to security
>> +;; models.
>> +;;
>> +;; The sys.role security identifier is associated with role
>> attribute in a
>> +;; security context used to associate with types with the Role-based
>> +;; access control security model.
>> +;;
>> +;; Note that we insert into the previously defined CIL "sys"
>> "container" here
>> +;;
>> +
>> +(in sys (role role))
>> +
>> +;;
>> +;; Security identifier declarations
>> +;;
>> +;; Security contexts are identifiers that are combinations of
>> security
>> +;; attribute and security identifier key value pairs corresponding
>> to security
>> +;; models.
>> +;;
>> +;; The sys.isid security identifier is associated with type
>> attribute in a
>> +;; security context used to enforce integrity with the Type-
>> enforcement
>> +;; security model.
>> +;;
>> +;; Note that we insert into the previously defined CIL "sys"
>> "container" here
>> +;;
>> +
>> +(in sys (type isid))
>> +
>> +;;
>> +;; Sensitivity ordering:
>> +;;
>> +;; Usually there are multiple sensitivities declared. Sensitivities
>> represent
>> +;; a hierarchy. Since we only have one sensitivity our sensitivity
>> order is
>> +;; simple.
>> +;;
>> +
>> +(sensitivityorder (s0))
>> +
>> +;;
>> +;; Category ordering:
>> +;;
>> +;; Usually there are multiple categories declared. Categories
>> represent
>> +;; a hierarchy. Since we only have one category our category order
>> is
>> +;; simple.
>> +;;
>> +
>> +(categoryorder (c0))
>> +
>> +;;
>> +;; Security identifier authorisations
>> +;;
>> +;; The individually declared security identifiers need to be
>> authorized to
>> +;; associate to be able to define valid security contexts.
>> +;;
>> +;; Authorize the s0 sensitivity with c0 category association
>> +;;
>> +
>> +(sensitivitycategory s0 (range c0 c0))
>> +
>> +;;
>> +;; Security identifier authorisations
>> +;;
>> +;; The individually declared security identifiers need to be
>> authorized to
>> +;; associate to be able to define valid security contexts.
>> +;;
>> +;; Authorize the sys.id user with sys.role role association
>> +;;
>> +
>> +(userrole sys.id sys.role)
>> +
>> +;;
>> +;; Security identifier authorisations
>> +;;
>> +;; The individually declared security identifiers need to be
>> authorized to
>> +;; associate to be able to define valid security contexts.
>> +;;
>> +;; Authorize the sys.role role with sys.isid type association
>> +;;
>> +
>> +(roletype sys.role sys.isid)
>> +
>> +;;
>> +;; Security identifier authorisations
>> +;;
>> +;; The individually declared security identifiers need to be
>> authorized to
>> +;; associate to be able to define valid security contexts.
>> +;;
>> +;; Authorize the sys.id user with s0 lavel association
>> +;;
>> +
>> +(userlevel sys.id (s0))
>> +
>> +;;
>> +;; Security identifier authorisations
>> +;;
>> +;; The individually declared security identifiers need to be
>> authorized to
>> +;; associate to be able to define valid security contexts.
>> +;;
>> +;; Authorize the sys.id user with s0-s0:c0.c0 range association
>> +;;
>> +
>> +(userrange sys.id ((s0)(s0 (range c0 c0))))
>> +
>> +;;
>> +;; Security context specifications:
>> +;;
>> +;; We will change the default role behavior to inherit the role from
>> the source
>> +;; instead of the target, as this allows us to leverage roles
>> associated with
>> +;; files.
>> +;;
>> +
>> +(defaultrole blk_file source)
>> +(defaultrole chr_file source)
>> +(defaultrole dir source)
>> +(defaultrole fifo_file source)
>> +(defaultrole file source)
>> +(defaultrole lnk_file source)
>> +(defaultrole sock_file source)
>> +
>> +;;
>> +;; Security context specifications
>> +;;
>> +;; Now that we have a valid security context:
>> sys.id:sys.role:sys.isid:s0-s0,
>> +;; associate it with the used initial sids.
>> +;;
>> +
>> +(sidcontext kernel (sys.id sys.role sys.isid ((s0)(s0))))
>> +(sidcontext security (sys.id sys.role sys.isid ((s0)(s0))))
>> +(sidcontext port (sys.id sys.role sys.isid ((s0)(s0))))
>> +(sidcontext netif (sys.id sys.role sys.isid ((s0)(s0))))
>> +(sidcontext netmsg (sys.id sys.role sys.isid ((s0)(s0))))
>> +(sidcontext node (sys.id sys.role sys.isid ((s0)(s0))))
>> +(sidcontext devnull (sys.id sys.role sys.isid ((s0)(s0))))
>> +(sidcontext file (sys.id sys.role sys.isid ((s0)(s0))))
>> +(sidcontext unlabeled (sys.id sys.role sys.isid ((s0)(s0))))
>> +
>> +;;
>> +;; Security context specifications
>> +;;
>> +;; Now that we have a valid security context:
>> sys.id:sys.role:sys.isid:s0-s0,
>> +;; associate it with locations on the filesystems so that they can
>> be
>> +;; associated with inodes on filesystems that support extended
>> security
>> +;; attributes.
>> +;;
>> +
>> +(filecon "/" dir (sys.id sys.role sys.isid ((s0)(s0))))
>> +(filecon "/.*" any (sys.id sys.role sys.isid ((s0)(s0))))
>> +
>> +;;
>> +;; AVC rule
>> +;;
>> +;; CIL requires us to specify at least one AVC rule Since we were
>> required
>> +;; to at least declare the process security class and its
>> dyntransition and
>> +;; transition access vector permissions. lets just add a AVC rule
>> allowing
>> +;; entities associated with our sys.isid type identifier access to
>> all process
>> +;; access vectors.
>> +;;
>> +
>> +(allow sys.isid self (process (all)))
>> +
>> +;;
>> +;; Tidy some loose ends
>> +;;
>> +;; Addressing a hard coded reference to a rpm_script_t type
>> identifier in RPM
>> +;; using typealiases to our sys.isid type so that RPM does not get
>> confused.
>> +
>> +(typealias rpm_script_t)
>> +(typealiasactual rpm_script_t sys.isid)
>> +
>> +(typealias dpkg_script_t)
>> +(typealiasactual dpkg_script_t sys.isid)
>> +
>> +;;
>> +;; Tidy some loose ends
>> +;;
>> +;; Generate a /etc/selinux/cil-policy/seusers file with a
>> __default__ fall back
>> +;; entry so that Linux users with be associated with the sys.id
>> SELinux
>> +;; identity and s0-s0 level.
>> +;;
>> +
>> +(selinuxuserdefault sys.id ((s0)(s0)))
>> +
>> +;;
>> +;; Tidy some loose ends
>> +;;
>> +;; We are associating valid roles with files. The userprefix
>> statement was
>> +;; recycled to allow us to tell genhomedircon what roles to
>> associate with
>> +;; SELinux identities associated with custmizable files (mainly
>> /home/user)
>> +;;
>> +
>> +(userprefix sys.id sys.role)
>> +
>> +;;
>> +;; Tidy some loose ends
>> +;;
>> +;; At the least /dev and /dev/pts need to be set up for labeling for
>> sudo
>> +;;
>> +
>> +(fsuse trans "devtmpfs" (sys.id sys.role sys.isid ((s0)(s0))))
>> +(fsuse trans "devpts" (sys.id sys.role sys.isid ((s0)(s0))))
>