| Message ID | 20200718104842.1333101-1-dominick.grift@defensec.nl (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [SELinux-notebook,v4] adds CIL policy with makefile | expand |
On Sat, 2020-07-18 at 12:48 +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 > > Signed-off-by: Dominick Grift <dominick.grift@defensec.nl> > --- > v2: rename XWAYLAND.md to XSERVER_XWAYLAND.md and cover both Xserver > as well as Xwayland > V3: fix typo in XSERVER_XWAYLAND.md and exclude x_contexts altogether > v4: remove XSERVER_XWAYLAND and add the note to README.md, redo > README.md and clean up cil-policy.cil > > src/cil_overview.md | 11 + > src/notebook-examples/README.md | 2 + > src/notebook-examples/cil-policy/Makefile | 31 ++ > src/notebook-examples/cil-policy/README.md | 90 ++++ > .../cil-policy/cil-policy.cil | 448 > ++++++++++++++++++ > 5 files changed, 582 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/cil-policy.cil > Acked-by: Richard Haines <richard_c_haines@btinternet.com> > 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..bb44f32 > --- /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 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))))
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..bb44f32 --- /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 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))))
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 Signed-off-by: Dominick Grift <dominick.grift@defensec.nl> --- v2: rename XWAYLAND.md to XSERVER_XWAYLAND.md and cover both Xserver as well as Xwayland V3: fix typo in XSERVER_XWAYLAND.md and exclude x_contexts altogether v4: remove XSERVER_XWAYLAND and add the note to README.md, redo README.md and clean up cil-policy.cil src/cil_overview.md | 11 + src/notebook-examples/README.md | 2 + src/notebook-examples/cil-policy/Makefile | 31 ++ src/notebook-examples/cil-policy/README.md | 90 ++++ .../cil-policy/cil-policy.cil | 448 ++++++++++++++++++ 5 files changed, 582 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/cil-policy.cil