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..ec60834
--- /dev/null
+++ b/src/notebook-examples/cil-policy/Makefile
@@ -0,0 +1,31 @@
+# -*- 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
+	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..7097fd7
--- /dev/null
+++ b/src/notebook-examples/cil-policy/README.md
@@ -0,0 +1,90 @@
+# Tiny CIL policy that is mutable at runtime
+
+The purpose of this tiny SELinux policy is to demonstrate what is
+least required to get started, and it can be used as a base for your
+own security policy or just to experiment with. The policy is written
+in Common Intermediate Language and is installed with semodule to
+provide easy access to all aspects at runtime.
+
+A single security context is provided that is associated with
+everything in memory only and to really get started you are expected
+to make an inventory of your filesystems and to enable labeling
+support for your filesystems accordingly before you proceed.
+
+Only eight security classes and two access vector permissions are
+declared. AVC allow rules for these two access vector permissions are
+associated with the single security context to give full access.
+Unknown access vectors are allowed to enable you to pick and choose
+which access vectors to leverage. You can get a list of unknown Linux
+security classes and access vector permissions from `dmesg`, and any
+user space object managers are likely to report unknown access vectors
+using either "USER_AVC" or "USER_SELINUX_ERR" type audit records. You
+are expected to declare any access vectors you require and then to
+associate them accordingly with access vector rules to allow access.
+
+The type-enforcement (TE), as well as identity-based (IBAC) and
+role-based (RBAC) access control security models are enabled. Optional
+security models such as multi-level security can be added with
+relative easy.
+
+Common Intermediate Language is a modern source based policy language
+that together with a module store that can be accessed with `semodule`
+at runtime provides optimal flexibility in your interactions with
+SELinux. It is recommended that you use the `setools` policy analysis
+suite to its full potential to get any information about the state of
+your policy.
+
+The cil-policy addresses some of the intricacies involved with getting
+started without making assumptions about your environment and
+requirements. You are enouraged to leverage CIL to its full potential
+and to keep its documentation handy.
+
+## Getting started
+
+```
+make install
+cat > /etc/selinux/config <<EOF
+SELINUX=enforcing
+SELINUXTYPE=cil-policy
+EOF
+```
+
+If you are switching to cil-policy from another policy then a system
+reboot is not strictly required:
+
+```
+semodule -B
+```
+
+Your first step to actually leverage cil-policy will likely be to
+enable labeling support for at least 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:
+
+```
+echo '(fsuse xattr "ext4" (sys.id sys.role sys.isid ((s0)(s0))))' > myfs.cil
+semodule -i myfs.cil
+fixfiles -F onboot && reboot
+```
+
+To modify the existing cil-policy:
+
+```
+semodule -E cil-policy
+emacs cil-policy.cil
+semodule -X 101 -i cil-policy.cil
+```
+
+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`.
+
+## Important
+
+If you are using Xserver or Xwayland then the following is required:
+
+```
+echo "(boolean xserver_object_manager false)" > disablexace.cil
+semodule -i disablexace.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..9289403
--- /dev/null
+++ b/src/notebook-examples/cil-policy/cil-policy.cil
@@ -0,0 +1,448 @@
+;; -*- 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 security classes and access vector permissions. Use
+;; `dmesg | grep -i selinux` to see which security classes and access vector
+;; permissions managed by Linux can be leveraged in the policy.
+;;
+
+(handleunknown allow)
+
+;;
+;; Policy configuration.
+;;
+;; Disable the MLS security model support for simplicity, but CIL still
+;; requires us to write our policy with minimal MLS-awareness. Remember that we
+;; can always add full or partial Multi-level security support later.
+;;
+
+(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 access vector rule as well so this is a good
+;; starting point. All security classes can be "unordered" with
+;; Linux 5.7/SELinux 3.1 but we are still required to use the classorder
+;; statement to do so.
+;;
+
+(class process (dyntransition transition))
+(classorder (unordered process))
+
+;;
+;; Access vector declarations and (un)ordering.
+;;
+;; To be able to associate roles with files we leverage defaultrole rules that
+;; require file security classes to be declared. Their associated access vector
+;; permissions are omitted for simplicity and to allow one to pick and choose
+;; permissions that one may want to leverage in the policy.
+;;
+
+(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 devnull initial security identifier is used to associate a specified
+;; security context with "fixed" null device objects used to enforce access
+;; control on file operations, for example read.
+;;
+
+(sid devnull)
+
+;;
+;; Initial security identifier declarations.
+;;
+;; The file initial security identifier is used to associate a specified
+;; security context with objects that have no label, for example formatted
+;; filesystems that are not labeled.
+;;
+
+(sid file)
+
+;;
+;; Initial security identifier declarations.
+;;
+;; The kernel initial security identifier is used to associate a specified
+;; security context with processes that were initialized before SELinux was
+;; initialized, for example kernel threads.
+;;
+
+(sid kernel)
+
+;;
+;; Initial security identifier declarations.
+;;
+;; The netif initial security identifier is used to associate a specified
+;; security context with "fixed" network interface objects used to enforce
+;; access control on network operations, for example egress.
+;;
+
+(sid netif)
+
+;;
+;; Initial security identifier declarations.
+;;
+;; The netmsg initial security identifier is used to associate a specified
+;; security 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 initial security identifier is used to associate a specified
+;; security context with "fixed" network node objects used to enforce access
+;; control on network operations, for example node_bind.
+;;
+
+(sid node)
+
+;;
+;; Initial security identifier declarations.
+;;
+;; The port initial security identifier is used to associate a specified
+;; security context with "fixed" network port objects used to enforce access
+;; control on network operations, for example name_connect.
+;;
+
+(sid port)
+
+;;
+;; Initial security identifier declarations.
+;;
+;; The security initial security identifier is used to associate a specified
+;; security context with "fixed" SELinux objects used to enforce access
+;; control on SELinux operations, for example setenforce.
+;;
+
+(sid security)
+
+;;
+;; Initial security identifier declarations.
+;;
+;; The unlabeled initial security identifier is used to associate a specified
+;; security context with entities that had their security context invalidated,
+;; for example due to modifications to policy at runtime.
+;;
+
+(sid unlabeled)
+
+;;
+;; Initial security identifier declarations (unused).
+;;
+;; The following initial security identifiers are unused but they have to be
+;; declared because they are referenced for required SID ordering next.
+;;
+
+(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.
+;;
+
+(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 the 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 the 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 the user attribute in a
+;; security context used to associate with Linux DAC, role and level security
+;; identifiers with the Identity-based access control security model.
+;;
+;; Note that we leverage a simple CIL container identified by "sys" 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 the 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 "sys" CIL 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 the type attribute in a
+;; security context used to enforce integrity with the Type-enforcement
+;; security model.
+;;
+;; Note that we insert into the previously defined "sys" CIL 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 authorizations.
+;;
+;; The individually declared security identifiers have to be authorized to
+;; associate to be able to combine into valid security contexts.
+;;
+;; Authorize the s0 sensitivity with c0 category association.
+;;
+
+(sensitivitycategory s0 (range c0 c0))
+
+;;
+;; Security identifier authorizations.
+;;
+;; The individually declared security identifiers have to be authorized to
+;; associate to be able to combine into valid security contexts.
+;;
+;; Authorize the sys.id user with sys.role role association.
+;;
+
+(userrole sys.id sys.role)
+
+;;
+;; Security identifier authorizations.
+;;
+;; The individually declared security identifiers have to be authorized to
+;; associate to be able to combine into valid security contexts.
+;;
+;; Authorize the sys.role role with sys.isid type association.
+;;
+
+(roletype sys.role sys.isid)
+
+;;
+;; Security identifier authorizations.
+;;
+;; The individually declared security identifiers have to be authorized to
+;; associate to be able to combine into valid security contexts.
+;;
+;; Authorize the sys.id user with s0 lavel association.
+;;
+
+(userlevel sys.id (s0))
+
+;;
+;; Security identifier authorizations.
+;;
+;; The individually declared security identifiers have to be authorized to
+;; associate to be able to combine into 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.
+;;
+;; Leverage role security identifiers associated with files by specifying that
+;; role identifiers associated with file security classes should be inherited
+;; from the source.
+;;
+
+(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.
+;;
+;; Associate our valid security context sys.id:sys.role:sys.isid:s0-s0 with
+;; the used initial security identifiers.
+;;
+
+(sidcontext devnull (sys.id sys.role sys.isid ((s0)(s0))))
+(sidcontext file (sys.id sys.role sys.isid ((s0)(s0))))
+(sidcontext kernel (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 port (sys.id sys.role sys.isid ((s0)(s0))))
+(sidcontext security (sys.id sys.role sys.isid ((s0)(s0))))
+(sidcontext unlabeled (sys.id sys.role sys.isid ((s0)(s0))))
+
+;;
+;; Security context specifications
+;;
+;; Associate our valid security context sys.id:sys.role:sys.isid:s0-s0 with
+;; locations on the filesystems so that they can be associated with inodes on
+;; filesystems that support security extended attributes.
+;;
+
+(filecon "/" dir (sys.id sys.role sys.isid ((s0)(s0))))
+(filecon "/.*" any (sys.id sys.role sys.isid ((s0)(s0))))
+
+;;
+;; Access vector rule.
+;;
+;; CIL requires us to specify at least one AVC rule and since we were required
+;; to at least declare the process security class, its dyntransition and
+;; transition access vector permissions, let's add a AVC rule allowing
+;; entities associated with our sys.isid type identifier access to all the
+;; process operations.
+;;
+
+(allow sys.isid self (process (all)))
+
+;;
+;; Tidy some loose ends.
+;;
+;; Address hardcoded references in Red Hat's and Debian's package managers
+;; with the typealiase statement.
+;;
+
+(typealias dpkg_script_t)
+(typealiasactual dpkg_script_t sys.isid)
+
+(typealias rpm_script_t)
+(typealiasactual rpm_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 are associated with the sys.id SELinux
+;; identity and the s0-s0 level.
+;;
+
+(selinuxuserdefault sys.id ((s0)(s0)))
+
+;;
+;; Tidy some loose ends.
+;;
+;; Leverage the userprefix statement to associate valid role identifiers with
+;; files generated by the genhomedircon command.
+;;
+
+(userprefix sys.id sys.role)
+
+;;
+;; Tidy some loose ends.
+;;
+;; At the least /dev and /dev/pts should be assumed to exist and be set up
+;; for labeling so that terminals can be relabeled.
+;;
+
+(fsuse trans "devpts" (sys.id sys.role sys.isid ((s0)(s0))))
+(fsuse trans "devtmpfs" (sys.id sys.role sys.isid ((s0)(s0))))
