[PATCH] selinux-testsuite: update to work on Debian

[PATCH] selinux-testsuite: update to work on Debian

[Stephen Smalley]

Update the testsuite policy and code so that it builds and
runs on Debian unstable and stable successfully (if one has
already enabled SELinux on Debian).  Provide the necessary
dependencies and instructions in the README.

The labeled networking tests relies on specific mlsconstrain
statements that exist in Fedora policy but not in Debian so
add them to the test policy as a CIL module; on Fedora this is
redundant but harmless.  The SCTP tests also assumed that
netlabel_peer_t was already marked mcs_constrained() in the
base policy which doesn't appear to be true in Debian, so mark
it so in the test policy.

The filesystem tests assume the defaultrange rules in the Fedora
policy for file MLS/MCS label inheritance, so add those rules as
a CIL module to the test policy to get the expected results.
Again, on Fedora this is a no-op.

Debian has no allow_domain_fd_use boolean so conditionalize the
setting of it.  The real boolean name in policy in Fedora is
domain_fd_use; allow_domain_fd_use was an old name that was being
mapped by userspace.

corenet_tcp/udp_sendrecv_all_ports() is an obsolete interface
that no longer exists in refpolicy.

mmap_file_perms is an obsolete macro that is deprecated in refpolicy
and removed in Debian policy; switch to mmap_exec_file_perms.

Rather than forcing the process user identity to system_u in the
filesystem tests (which broke in Debian due to not being authorized
for unconfined_r), grant the test_filesystem_fscontext_t domain
the ability to create objects in other user identities.  This is
cleaner.

Switch the Infiniband test policy to use the appropriate policy
interface if defined rather than hardcoding a reference to the
type, neither of which exist in Debian policy.  Drop the dead
hardcoded reference on bin_t since it is no longer used anywhere
outside of an interface.

Convert the network test policies from using bind/connect_generic_port()
to using bind/connect_all_unreserved_ports(), since the actual port
being used falls in the unreserved port range and the _generic_port()
interfaces do not allow access in Debian and likely refpolicy.

Update the overlayfs policy to allow the test_overlay_mounter_t
domain to read a shell-created temporary file that ends up being
labeled user_tmp_t in Debian; this occurs during setup-overlayfs
and otherwise breaks mounting.

Replace the reference to unconfined_devpts_t which does not exist
in Debian policy with the more general ptynode attribute.

Debian does not allow unprivileged user namespace clones by default,
so update the test to enable it when running the test to avoid requiring
sys_admin permission to the capability class during the cap_userns tests.

Debian unstable is mounting devtmpfs as noexec which breaks
testing of mmap/mprotect PROT_EXEC /dev/zero, so skip those tests
if so mounted.

Fixes: https://github.com/SELinuxProject/selinux-testsuite/issues/73
Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
---
 README.md                            | 62 +++++++++++++++++++++++++++-
 policy/Makefile                      | 10 ++++-
 policy/test_capable_net.te           |  2 -
 policy/test_execute_no_trans.te      |  2 +-
 policy/test_filesystem.te            |  1 +
 policy/test_global.te                |  1 +
 policy/test_ibendport.te             |  9 ++--
 policy/test_inet_socket.te           | 22 +++++-----
 policy/test_mlsconstrain.cil         |  2 +
 policy/test_overlay_defaultrange.cil |  7 ++++
 policy/test_overlayfs.te             |  1 +
 policy/test_policy.if                |  4 +-
 policy/test_sctp.te                  |  1 +
 tests/cap_userns/test                |  8 ++++
 tests/filesystem/test                |  2 +-
 tests/fs_filesystem/test             |  2 +-
 tests/mmap/test                      | 49 ++++++++++++++--------
 17 files changed, 141 insertions(+), 44 deletions(-)
 create mode 100644 policy/test_mlsconstrain.cil
 create mode 100644 policy/test_overlay_defaultrange.cil

diff --git a/README.md b/README.md
index b36494e..0d3f060 100644
--- a/README.md
+++ b/README.md
@@ -36,6 +36,8 @@ one primary security module may be active at a time.
 
 ### Userland and Base Policy
 
+#### Fedora or RHEL
+
 On a Fedora/RHEL based system the testsuite has the following userspace
 dependencies beyond a minimal install (other Linux distributions should have
 similar dependencies):
@@ -77,8 +79,66 @@ following command:
 		xfsprogs-devel \
 		libuuid-devel
 
+#### Debian
+
+On Debian, you must first take steps to install and activate SELinux since
+it is not enabled in the default install.  Be sure to backup your system first
+if you care about any local data.
+
+	# apt-get install selinux-basics selinux-policy-default auditd
+	# selinux-activate
+	# reboot
+
+After activating, make sure that your login shell is running in the correct context:
+
+	# id -Z
+
+If this shows something other than "unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023",
+you will need to first fix labeling or policy problems in your base system before proceeding.
+Be sure that your shell context is correct and you can switch to enforcing mode without
+breaking your system before proceeding.
+
+On Debian, you can install the userspace dependencies with the following
+command:
+
+	# apt-get install perl \
+		gcc \
+		selinux-policy-dev \
+		libselinux1-dev \
+		net-tools \
+		iptables \
+		libsctp-dev \
+		attr \
+		libbpf-dev \
+		libkeyutils-dev \
+		linux-headers-$(uname -r) \
+		quota \
+		xfsprogs \
+		xfslibs-dev \
+		uuid-dev
+
+On Debian, you need to build and install netlabel_tools manually since it is not
+yet packaged for Debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959806):
+
+    # git clone https://github.com/netlabel/netlabel_tools
+    # cd netlabel_tools
+    # sudo apt-get install autotools-dev autoconf automake libtool pkg-config libnl-3-dev libnl-genl-3-dev
+    # ./autogen.sh
+    # ./configure --prefix=/usr
+    # make
+    # sudo make install
+
+Debian further requires reconfiguring the default /bin/sh to be bash
+to support bashisms employed in the testsuite Makefiles and scripts:
+
+    # dpkg-reconfigure dash
+
+Select No when asked if you want to use dash as the default system shell.
+
+#### Other Distributions
+
 The testsuite requires a pre-existing base policy configuration of SELinux,
-using either the old example policy or the reference policy as the baseline.
+using the reference policy as the baseline.
 It also requires the core SELinux userland packages (`libsepol`, `checkpolicy`,
 `libselinux`, `policycoreutils`, and if using modular policy, `libsemanage`)
 to be installed.  The test scripts also rely upon the SELinux extensions being
diff --git a/policy/Makefile b/policy/Makefile
index dfe601b..f86aac4 100644
--- a/policy/Makefile
+++ b/policy/Makefile
@@ -40,6 +40,8 @@ CIL_TARGETS = test_add_levels.cil test_glblub.cil
 endif
 endif # GLBLUB
 
+CIL_TARGETS += test_mlsconstrain.cil test_overlay_defaultrange.cil
+
 ifeq ($(shell [ $(POL_VERS) -ge 24 ] && echo true),true)
 TARGETS += test_bounds.te test_nnp_nosuid.te
 endif
@@ -161,12 +163,16 @@ build: $(TARGETS)
 
 load: expand_check all
 	# General policy load
-	@-/usr/sbin/setsebool allow_domain_fd_use=0
+	@if [ -e /sys/fs/selinux/booleans/domain_fd_use ]; then \
+		/usr/sbin/setsebool domain_fd_use=0; \
+	fi
 	$(SEMODULE) -i test_policy/test_policy.pp $(CIL_TARGETS)
 
 unload:
 	# General policy unload
-	@-/usr/sbin/setsebool allow_domain_fd_use=1
+	@if [ -e /sys/fs/selinux/booleans/domain_fd_use ]; then \
+		/usr/sbin/setsebool domain_fd_use=1; \
+	fi
 	$(SEMODULE) -r test_policy $(subst .cil,,$(CIL_TARGETS))
 
 clean:
diff --git a/policy/test_capable_net.te b/policy/test_capable_net.te
index 80559f6..2255a14 100644
--- a/policy/test_capable_net.te
+++ b/policy/test_capable_net.te
@@ -28,8 +28,6 @@ corenet_raw_sendrecv_generic_if(capabledomain)
 corenet_tcp_sendrecv_all_nodes(capabledomain)
 corenet_udp_sendrecv_all_nodes(capabledomain)
 corenet_raw_sendrecv_all_nodes(capabledomain)
-corenet_tcp_sendrecv_all_ports(capabledomain)
-corenet_udp_sendrecv_all_ports(capabledomain)
 corenet_all_recvfrom_unlabeled(test_ncap_t)
 corenet_all_recvfrom_unlabeled(test_resncap_t)
 corenet_tcp_bind_all_nodes(capabledomain)
diff --git a/policy/test_execute_no_trans.te b/policy/test_execute_no_trans.te
index 79ba868..f699f56 100644
--- a/policy/test_execute_no_trans.te
+++ b/policy/test_execute_no_trans.te
@@ -24,4 +24,4 @@ userdom_sysadm_entry_spec_domtrans_to(test_execute_notrans_t)
 
 #Allow test_execute_notrans permissions to the allowed type
 can_exec(test_execute_notrans_t,test_execute_notrans_allowed_t)
-allow test_execute_notrans_t test_execute_notrans_denied_t:file mmap_file_perms;
+allow test_execute_notrans_t test_execute_notrans_denied_t:file mmap_exec_file_perms;
diff --git a/policy/test_filesystem.te b/policy/test_filesystem.te
index 7d73cbf..4e27134 100644
--- a/policy/test_filesystem.te
+++ b/policy/test_filesystem.te
@@ -350,6 +350,7 @@ allow test_filesystem_fscontext_t test_filesystem_filecon_t:file { getattr open
 allow test_filesystem_fscontext_t test_filesystem_fscontext_fs_t:dir { add_name search write };
 allow test_filesystem_fscontext_t test_filesystem_fscontext_fs_t:file { create getattr open relabelfrom write };
 allow test_filesystem_fscontext_t test_filesystem_fscontext_fs_t:filesystem { mount relabelto unmount };
+domain_obj_id_change_exemption(test_filesystem_fscontext_t)
 fs_relabelfrom_all_fs(test_filesystem_fscontext_t)
 files_search_all(test_filesystem_fscontext_t)
 allow test_filesystem_filecon_t test_filesystem_fscontext_fs_t:filesystem { associate };
diff --git a/policy/test_global.te b/policy/test_global.te
index c9520ec..d19b4be 100644
--- a/policy/test_global.te
+++ b/policy/test_global.te
@@ -83,6 +83,7 @@ domain_use_interactive_fds(testdomain)
 seutil_read_config(testdomain)
 
 # can getsecurity
+selinux_getattr_fs(testdomain)
 selinux_validate_context(testdomain)
 selinux_compute_access_vector(testdomain)
 selinux_compute_create_context(testdomain)
diff --git a/policy/test_ibendport.te b/policy/test_ibendport.te
index 2a02c57..b909b4f 100644
--- a/policy/test_ibendport.te
+++ b/policy/test_ibendport.te
@@ -3,11 +3,6 @@
 # Policy for testing Infiniband Pkey access.
 #
 
-gen_require(`
-	type bin_t;
-	type infiniband_mgmt_device_t;
-')
-
 attribute ibendportdomain;
 
 # Domain for process.
@@ -27,7 +22,9 @@ dev_rw_sysfs(test_ibendport_manage_subnet_t)
 
 corecmd_bin_entry_type(test_ibendport_manage_subnet_t)
 
-allow test_ibendport_manage_subnet_t infiniband_mgmt_device_t:chr_file { read write open ioctl};
+ifdef(`dev_rw_infiniband_mgmt_dev', `
+dev_rw_infiniband_mgmt_dev(test_ibendport_manage_subnet_t)
+')
 
 ifdef(`corenet_ib_access_unlabeled_pkeys',`
 corenet_ib_access_unlabeled_pkeys(test_ibendport_manage_subnet_t)
diff --git a/policy/test_inet_socket.te b/policy/test_inet_socket.te
index bf839df..0fff2da 100644
--- a/policy/test_inet_socket.te
+++ b/policy/test_inet_socket.te
@@ -26,8 +26,8 @@ typeattribute test_inet_server_t testdomain;
 typeattribute test_inet_server_t inetsocketdomain;
 allow test_inet_server_t self:tcp_socket create_stream_socket_perms;
 allow test_inet_server_t self:udp_socket create_socket_perms;
-corenet_tcp_bind_generic_port(test_inet_server_t)
-corenet_udp_bind_generic_port(test_inet_server_t)
+corenet_tcp_bind_all_unreserved_ports(test_inet_server_t)
+corenet_udp_bind_all_unreserved_ports(test_inet_server_t)
 corenet_tcp_bind_all_nodes(test_inet_server_t)
 corenet_udp_bind_all_nodes(test_inet_server_t)
 corenet_inout_generic_if(test_inet_server_t)
@@ -54,7 +54,7 @@ typeattribute test_inet_client_t testdomain;
 typeattribute test_inet_client_t inetsocketdomain;
 allow test_inet_client_t self:tcp_socket create_stream_socket_perms;
 allow test_inet_client_t self:udp_socket create_socket_perms;
-corenet_tcp_connect_generic_port(test_inet_client_t)
+corenet_tcp_connect_all_unreserved_ports(test_inet_client_t)
 corenet_inout_generic_if(test_inet_client_t)
 corenet_inout_generic_node(test_inet_client_t)
 
@@ -71,7 +71,7 @@ typeattribute test_inet_bad_client_t testdomain;
 typeattribute test_inet_bad_client_t inetsocketdomain;
 allow test_inet_bad_client_t self:tcp_socket create_stream_socket_perms;
 allow test_inet_bad_client_t self:udp_socket create_socket_perms;
-corenet_tcp_connect_generic_port(test_inet_bad_client_t)
+corenet_tcp_connect_all_unreserved_ports(test_inet_bad_client_t)
 corenet_inout_generic_if(test_inet_bad_client_t)
 corenet_inout_generic_node(test_inet_bad_client_t)
 
@@ -87,8 +87,8 @@ typeattribute test_inet_bind_t testdomain;
 typeattribute test_inet_bind_t inetsocketdomain;
 allow test_inet_bind_t self:tcp_socket create_stream_socket_perms;
 allow test_inet_bind_t self:udp_socket create_socket_perms;
-corenet_tcp_bind_generic_port(test_inet_bind_t)
-corenet_udp_bind_generic_port(test_inet_bind_t)
+corenet_tcp_bind_all_unreserved_ports(test_inet_bind_t)
+corenet_udp_bind_all_unreserved_ports(test_inet_bind_t)
 corenet_tcp_bind_all_nodes(test_inet_bind_t)
 corenet_udp_bind_all_nodes(test_inet_bind_t)
 
@@ -111,8 +111,8 @@ typeattribute test_inet_no_node_bind_t testdomain;
 typeattribute test_inet_no_node_bind_t inetsocketdomain;
 allow test_inet_no_node_bind_t self:tcp_socket create_stream_socket_perms;
 allow test_inet_no_node_bind_t self:udp_socket create_socket_perms;
-corenet_tcp_bind_generic_port(test_inet_no_node_bind_t)
-corenet_udp_bind_generic_port(test_inet_no_node_bind_t)
+corenet_tcp_bind_all_unreserved_ports(test_inet_no_node_bind_t)
+corenet_udp_bind_all_unreserved_ports(test_inet_no_node_bind_t)
 
 # Domain for a process allowed to connect(2).
 type test_inet_connect_t;
@@ -122,8 +122,8 @@ typeattribute test_inet_connect_t testdomain;
 typeattribute test_inet_connect_t inetsocketdomain;
 allow test_inet_connect_t self:tcp_socket create_stream_socket_perms;
 allow test_inet_connect_t self:udp_socket create_socket_perms;
-corenet_tcp_connect_generic_port(test_inet_connect_t)
-corenet_tcp_bind_generic_port(test_inet_connect_t)
+corenet_tcp_connect_all_unreserved_ports(test_inet_connect_t)
+corenet_tcp_bind_all_unreserved_ports(test_inet_connect_t)
 corenet_tcp_bind_all_nodes(test_inet_connect_t)
 corenet_inout_generic_if(test_inet_connect_t)
 corenet_inout_generic_node(test_inet_connect_t)
@@ -136,7 +136,7 @@ typeattribute test_inet_no_name_connect_t testdomain;
 typeattribute test_inet_no_name_connect_t inetsocketdomain;
 allow test_inet_no_name_connect_t self:tcp_socket create_stream_socket_perms;
 allow test_inet_no_name_connect_t self:udp_socket create_socket_perms;
-corenet_tcp_bind_generic_port(test_inet_no_name_connect_t)
+corenet_tcp_bind_all_unreserved_ports(test_inet_no_name_connect_t)
 corenet_tcp_bind_all_nodes(test_inet_no_name_connect_t)
 corenet_inout_generic_if(test_inet_no_name_connect_t)
 corenet_inout_generic_node(test_inet_no_name_connect_t)
diff --git a/policy/test_mlsconstrain.cil b/policy/test_mlsconstrain.cil
new file mode 100644
index 0000000..1412f91
--- /dev/null
+++ b/policy/test_mlsconstrain.cil
@@ -0,0 +1,2 @@
+(mlsconstrain (peer (recv)) (or (dom l1 l2) (and (neq t1 mcs_constrained_type) (neq t2 mcs_constrained_type))))
+(mlsconstrain (packet (recv)) (or (dom l1 l2) (and (neq t1 mcs_constrained_type) (neq t2 mcs_constrained_type))))
diff --git a/policy/test_overlay_defaultrange.cil b/policy/test_overlay_defaultrange.cil
new file mode 100644
index 0000000..d1c18db
--- /dev/null
+++ b/policy/test_overlay_defaultrange.cil
@@ -0,0 +1,7 @@
+(defaultrange file target low)
+(defaultrange dir target low)
+(defaultrange lnk_file target low)
+(defaultrange chr_file target low)
+(defaultrange blk_file target low)
+(defaultrange sock_file target low)
+(defaultrange fifo_file target low)
diff --git a/policy/test_overlayfs.te b/policy/test_overlayfs.te
index 6f1756e..b29621e 100644
--- a/policy/test_overlayfs.te
+++ b/policy/test_overlayfs.te
@@ -52,6 +52,7 @@ corecmd_exec_bin(test_overlay_mounter_t)
 
 userdom_search_admin_dir(test_overlay_mounter_t)
 userdom_search_user_home_content(test_overlay_mounter_t)
+userdom_read_user_tmp_files(test_overlay_mounter_t)
 
 mount_exec(test_overlay_mounter_t)
 mount_rw_pid_files(test_overlay_mounter_t)
diff --git a/policy/test_policy.if b/policy/test_policy.if
index cefc8fb..f0400f5 100644
--- a/policy/test_policy.if
+++ b/policy/test_policy.if
@@ -29,7 +29,7 @@
 interface(`unconfined_runs_test',`
 	gen_require(`
 		type unconfined_t;
-               type unconfined_devpts_t;
+               attribute ptynode;
 		role unconfined_r;
 	')
 
@@ -38,7 +38,7 @@ interface(`unconfined_runs_test',`
 	role unconfined_r types $1;
       # Report back from the test domain to the caller.
       allow $1 unconfined_t:fd use;
-      allow $1 unconfined_devpts_t:chr_file { read write ioctl getattr };
+      allow $1 ptynode:chr_file { read write ioctl getattr };
       allow $1 unconfined_t:fifo_file { read write ioctl getattr };
       allow $1 unconfined_t:process { sigchld };
 
diff --git a/policy/test_sctp.te b/policy/test_sctp.te
index df8606e..3b16db1 100644
--- a/policy/test_sctp.te
+++ b/policy/test_sctp.te
@@ -25,6 +25,7 @@ allow nfsd_t netlabel_sctp_peer_t:peer recv;
 gen_require(`
 	type netlabel_peer_t;
 ')
+mcs_constrained(netlabel_peer_t)
 
 #
 ############### Declare an attribute that will hold all peers ###############
diff --git a/tests/cap_userns/test b/tests/cap_userns/test
index 9eafba6..917da00 100755
--- a/tests/cap_userns/test
+++ b/tests/cap_userns/test
@@ -6,6 +6,10 @@ BEGIN {
     $basedir = $0;
     $basedir =~ s|(.*)/[^/]*|$1|;
 
+    if ( -e '/proc/sys/kernel/unprivileged_userns_clone' ) {
+        system(
+            "echo 1 > /proc/sys/kernel/unprivileged_userns_clone 2> /dev/null");
+    }
     if ( system("$basedir/userns_child_exec -t -U > /dev/null 2>&1") == 0 ) {
         plan tests => 2;
     }
@@ -27,3 +31,7 @@ $result = system(
 "runcon -t test_no_cap_userns_t -- $basedir/userns_child_exec -p -m -U -M '0 0 1' -G '0 0 1' -- true 2>&1"
 );
 ok($result);
+
+if ( -e '/proc/sys/kernel/unprivileged_userns_clone' ) {
+    system("echo 0 > /proc/sys/kernel/unprivileged_userns_clone 2> /dev/null");
+}
diff --git a/tests/filesystem/test b/tests/filesystem/test
index 149cc29..7d4654d 100755
--- a/tests/filesystem/test
+++ b/tests/filesystem/test
@@ -1116,7 +1116,7 @@ if ( not $nfs_enabled ) {
         #   system_u:object_r:test_filesystem_context_file_t:s0 from $test_opts
         print "Creating test file $basedir/mntpoint/mp1/test_file\n";
         $result = system(
-"runcon -u system_u -t test_filesystem_fscontext_t $basedir/create_file -f $basedir/mntpoint/mp1/test_file -e test_filesystem_context_file_t $v"
+"runcon -t test_filesystem_fscontext_t $basedir/create_file -f $basedir/mntpoint/mp1/test_file -e test_filesystem_context_file_t $v"
         );
         ok( $result eq 0 );
 
diff --git a/tests/fs_filesystem/test b/tests/fs_filesystem/test
index 5dcc89d..5dedf83 100755
--- a/tests/fs_filesystem/test
+++ b/tests/fs_filesystem/test
@@ -1145,7 +1145,7 @@ if ( not $nfs_enabled ) {
         #   system_u:object_r:test_filesystem_context_file_t:s0 from $test_opts
         print "Creating test file $basedir/mntpoint/mp1/test_file\n";
         $result = system(
-"runcon -u system_u -t test_filesystem_fscontext_t $filesystem_dir/create_file -f $basedir/mntpoint/mp1/test_file -e test_filesystem_context_file_t $v"
+"runcon -t test_filesystem_fscontext_t $filesystem_dir/create_file -f $basedir/mntpoint/mp1/test_file -e test_filesystem_context_file_t $v"
         );
         ok( $result eq 0 );
 
diff --git a/tests/mmap/test b/tests/mmap/test
index fe6f184..850b24f 100755
--- a/tests/mmap/test
+++ b/tests/mmap/test
@@ -3,10 +3,11 @@
 use Test;
 
 BEGIN {
-    $test_count         = 34;
-    $test_hugepages     = 0;
-    $test_exec_checking = 0;
-    $test_map_checking  = 0;
+    $test_count            = 30;
+    $test_hugepages        = 0;
+    $test_exec_checking    = 0;
+    $test_map_checking     = 0;
+    $test_devzero_checking = 0;
 
     system("echo 1 > /proc/sys/vm/nr_hugepages 2> /dev/null");
     if ( system("grep -q 1 /proc/sys/vm/nr_hugepages 2> /dev/null") == 0 ) {
@@ -19,6 +20,13 @@ BEGIN {
         $test_count += 4;
     }
 
+    if (
+        system("grep -q devtmpfs.*noexec /proc/self/mounts 2> /dev/null") != 0 )
+    {
+        $test_devzero_checking = 1;
+        $test_count += 4;
+    }
+
     if ( -e '/sys/fs/selinux/class/file/perms/map' ) {
         $test_map_checking = 1;
         $test_count += 1;
@@ -62,13 +70,17 @@ ok( $result, 0 );
 $result = system "runcon -t test_no_execmem_t $basedir/mmap_anon_shared 2>&1";
 ok($result);
 
-# Test success and failure for mmap /dev/zero.
-$result =
-  system "runcon -t test_mmap_dev_zero_t $basedir/mmap_file_shared /dev/zero";
-ok( $result, 0 );
-$result = system
-  "runcon -t test_no_mmap_dev_zero_t $basedir/mmap_file_shared /dev/zero 2>&1";
-ok($result);
+if ($test_devzero_checking) {
+
+    # Test success and failure for mmap /dev/zero.
+    $result =
+      system
+      "runcon -t test_mmap_dev_zero_t $basedir/mmap_file_shared /dev/zero";
+    ok( $result, 0 );
+    $result = system
+"runcon -t test_no_mmap_dev_zero_t $basedir/mmap_file_shared /dev/zero 2>&1";
+    ok($result);
+}
 
 # Test success and failure for mprotect w/ anonymous shared memory.
 # In old kernels, this triggers a tmpfs file execute check.
@@ -80,13 +92,16 @@ $result = system
   "runcon -t test_no_mprotect_anon_shared_t $basedir/mprotect_anon_shared 2>&1";
 ok($result);
 
-# Test success and failure for mprotect /dev/zero.
-$result = system
-  "runcon -t test_mprotect_dev_zero_t $basedir/mprotect_file_shared /dev/zero";
-ok( $result, 0 );
-$result = system
+if ($test_devzero_checking) {
+
+    # Test success and failure for mprotect /dev/zero.
+    $result = system
+"runcon -t test_mprotect_dev_zero_t $basedir/mprotect_file_shared /dev/zero";
+    ok( $result, 0 );
+    $result = system
 "runcon -t test_no_mprotect_dev_zero_t $basedir/mprotect_file_shared /dev/zero 2>&1";
-ok($result);
+    ok($result);
+}
 
 # Test success and failure for execheap, independent of execmem.
 $result = system "runcon -t test_execheap_t $basedir/mprotect_heap";
-- 
2.23.1

Re: [PATCH] selinux-testsuite: update to work on Debian

[Stephen Smalley]

On Tue, May 5, 2020 at 8:54 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> Update the testsuite policy and code so that it builds and
> runs on Debian unstable and stable successfully (if one has
> already enabled SELinux on Debian).  Provide the necessary
> dependencies and instructions in the README.

A few notes for anyone trying to run this on Debian:

1) There is an open bug in Debian around gdm login shells running in
the wrong context (initrc_t instead of unconfined_t),
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874191, due to the
/sys/fs/selinux/user ERANGE problem breaking pam_selinux for the
systemd --user instance and the lack of either a policy workaround (as
previously done in Fedora to limit outbound transitions from init_t to
only valid cases) or the recent libselinux fix (to stop using
/sys/fs/selinux/user altogether).  To permit testing without requiring
my own custom policy or libselinux, I simply ran the tests from a ssh
login rather than a graphical login.  Non-graphical console login
probably would have worked too but I didn't try. But I have escalated
the bug with the Debian SELinux maintainers in hopes of getting that
fixed.

2) In Debian unstable, I also had to setsebool -P ssh_sysadm_login=1
to allow ssh login as unconfined.  I let the Debian SELinux
maintainers know but it isn't clear they will change the default.

3) Debian policy package ships with /etc/selinux/config set to
permissive since the policy often doesn't work cleanly out of the box,
so I had to manually setenforce 1 before running the testsuite.  This
btw killed any gdm login sessions as well due to missing execmem and
other permissions so that's another reason to not do it from a gdm
login under their current policy.

4) The Debian stable kernel didn't enable CONFIG_NETLABEL so all of
the netlabel-dependent inet_socket tests failed on stable.  Debian
unstable kernel had CONFIG_NETLABEL enabled and they all passed there.
I didn't consider it worthwhile to build my own Debian stable kernel
for testing it; I just wanted to ensure that the policy worked, which
I consider the Debian unstable test to prove.

Interestingly, on Debian unstable, we end up running more tests than
on Fedora rawhide currently: 64 test scripts with 869 individual tests
versus 62 test scripts with 824 individual tests.  This is because
Debian unstable's policy (which is based on a recent snapshot of
refpolicy) has class and permission definitions for everything in its
kernel except the lockdown class, versus Fedora which lacks the watch*
permissions as well as the perf_event and lockdown classes.

Re: [PATCH] selinux-testsuite: update to work on Debian

[William Roberts]

On Wed, May 6, 2020 at 8:45 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Tue, May 5, 2020 at 8:54 PM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > Update the testsuite policy and code so that it builds and
> > runs on Debian unstable and stable successfully (if one has
> > already enabled SELinux on Debian).  Provide the necessary
> > dependencies and instructions in the README.
>
> A few notes for anyone trying to run this on Debian:
>
> 1) There is an open bug in Debian around gdm login shells running in
> the wrong context (initrc_t instead of unconfined_t),
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874191, due to the
> /sys/fs/selinux/user ERANGE problem breaking pam_selinux for the
> systemd --user instance and the lack of either a policy workaround (as
> previously done in Fedora to limit outbound transitions from init_t to
> only valid cases) or the recent libselinux fix (to stop using
> /sys/fs/selinux/user altogether).  To permit testing without requiring
> my own custom policy or libselinux, I simply ran the tests from a ssh
> login rather than a graphical login.  Non-graphical console login
> probably would have worked too but I didn't try. But I have escalated
> the bug with the Debian SELinux maintainers in hopes of getting that
> fixed.
>
> 2) In Debian unstable, I also had to setsebool -P ssh_sysadm_login=1
> to allow ssh login as unconfined.  I let the Debian SELinux
> maintainers know but it isn't clear they will change the default.
>
> 3) Debian policy package ships with /etc/selinux/config set to
> permissive since the policy often doesn't work cleanly out of the box,
> so I had to manually setenforce 1 before running the testsuite.  This
> btw killed any gdm login sessions as well due to missing execmem and
> other permissions so that's another reason to not do it from a gdm
> login under their current policy.
>
> 4) The Debian stable kernel didn't enable CONFIG_NETLABEL so all of
> the netlabel-dependent inet_socket tests failed on stable.  Debian
> unstable kernel had CONFIG_NETLABEL enabled and they all passed there.
> I didn't consider it worthwhile to build my own Debian stable kernel
> for testing it; I just wanted to ensure that the policy worked, which
> I consider the Debian unstable test to prove.
>
> Interestingly, on Debian unstable, we end up running more tests than
> on Fedora rawhide currently: 64 test scripts with 869 individual tests
> versus 62 test scripts with 824 individual tests.  This is because
> Debian unstable's policy (which is based on a recent snapshot of
> refpolicy) has class and permission definitions for everything in its
> kernel except the lockdown class, versus Fedora which lacks the watch*
> permissions as well as the perf_event and lockdown classes.

This is fantastic, I haven't looked at it fully yet. But I'm assuming this would
be the initial bulk work to get the make check on travis better. So in theory
we can just replicate this on Travis. Is my understanding correct here?
Ideally, we can get to a point where if CI is passing, its already an RC
candidate.

Re: [PATCH] selinux-testsuite: update to work on Debian

[Stephen Smalley]

On Wed, May 6, 2020 at 10:57 AM William Roberts
<bill.c.roberts@gmail.com> wrote:
>
> On Wed, May 6, 2020 at 8:45 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Tue, May 5, 2020 at 8:54 PM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > >
> > > Update the testsuite policy and code so that it builds and
> > > runs on Debian unstable and stable successfully (if one has
> > > already enabled SELinux on Debian).  Provide the necessary
> > > dependencies and instructions in the README.
> >
> > A few notes for anyone trying to run this on Debian:
> >
> > 1) There is an open bug in Debian around gdm login shells running in
> > the wrong context (initrc_t instead of unconfined_t),
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874191, due to the
> > /sys/fs/selinux/user ERANGE problem breaking pam_selinux for the
> > systemd --user instance and the lack of either a policy workaround (as
> > previously done in Fedora to limit outbound transitions from init_t to
> > only valid cases) or the recent libselinux fix (to stop using
> > /sys/fs/selinux/user altogether).  To permit testing without requiring
> > my own custom policy or libselinux, I simply ran the tests from a ssh
> > login rather than a graphical login.  Non-graphical console login
> > probably would have worked too but I didn't try. But I have escalated
> > the bug with the Debian SELinux maintainers in hopes of getting that
> > fixed.
> >
> > 2) In Debian unstable, I also had to setsebool -P ssh_sysadm_login=1
> > to allow ssh login as unconfined.  I let the Debian SELinux
> > maintainers know but it isn't clear they will change the default.
> >
> > 3) Debian policy package ships with /etc/selinux/config set to
> > permissive since the policy often doesn't work cleanly out of the box,
> > so I had to manually setenforce 1 before running the testsuite.  This
> > btw killed any gdm login sessions as well due to missing execmem and
> > other permissions so that's another reason to not do it from a gdm
> > login under their current policy.
> >
> > 4) The Debian stable kernel didn't enable CONFIG_NETLABEL so all of
> > the netlabel-dependent inet_socket tests failed on stable.  Debian
> > unstable kernel had CONFIG_NETLABEL enabled and they all passed there.
> > I didn't consider it worthwhile to build my own Debian stable kernel
> > for testing it; I just wanted to ensure that the policy worked, which
> > I consider the Debian unstable test to prove.
> >
> > Interestingly, on Debian unstable, we end up running more tests than
> > on Fedora rawhide currently: 64 test scripts with 869 individual tests
> > versus 62 test scripts with 824 individual tests.  This is because
> > Debian unstable's policy (which is based on a recent snapshot of
> > refpolicy) has class and permission definitions for everything in its
> > kernel except the lockdown class, versus Fedora which lacks the watch*
> > permissions as well as the perf_event and lockdown classes.
>
> This is fantastic, I haven't looked at it fully yet. But I'm assuming this would
> be the initial bulk work to get the make check on travis better. So in theory
> we can just replicate this on Travis. Is my understanding correct here?
> Ideally, we can get to a point where if CI is passing, its already an RC
> candidate.

That would be great but I don't think it is quite that easy
unfortunately. I'm not a travis-ci expert by any means, but I don't
think it provides us with a way to replicate the current steps
required to enable SELinux in Debian or Ubuntu.  Debian's current
approach to enabling SELinux involves installing some additional
packages, running a selinux-activate script to modify the kernel
command line in the grub configuration to enable SELinux in the kernel
and to update some other configurations (e.g. adding pam_selinux to
pam configs), rebooting to come up with SELinux enabled in the kernel
and to label all filesystems, and rebooting a second time to come up
with everything including init in the right SELinux domain.  In
contrast I think travis-ci just provides you with a stock Ubuntu LTS
image and allows you to install additional packages and run commands
on that running instance, but not to specify custom kernel parameters
initially or to reboot the system before proceeding with further
commands (if anyone knows differently, speak up). We'd have to get to
the point where enabling SELinux in Debian is possible without
requiring a reboot at all.  And then we'd have to wait for that
support to find its way into one of the Ubuntu images supported by
travis-ci.  Might be easier to just get travis-ci to support Fedora or
CentOS images in the first place. Regardless, allowing the testsuite
to be run by users of other distributions is worthwhile IMHO.

Re: [PATCH] selinux-testsuite: update to work on Debian

[William Roberts]

On Wed, May 6, 2020 at 10:50 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Wed, May 6, 2020 at 10:57 AM William Roberts
> <bill.c.roberts@gmail.com> wrote:
> >
> > On Wed, May 6, 2020 at 8:45 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > >
> > > On Tue, May 5, 2020 at 8:54 PM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > >
> > > > Update the testsuite policy and code so that it builds and
> > > > runs on Debian unstable and stable successfully (if one has
> > > > already enabled SELinux on Debian).  Provide the necessary
> > > > dependencies and instructions in the README.
> > >
> > > A few notes for anyone trying to run this on Debian:
> > >
> > > 1) There is an open bug in Debian around gdm login shells running in
> > > the wrong context (initrc_t instead of unconfined_t),
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874191, due to the
> > > /sys/fs/selinux/user ERANGE problem breaking pam_selinux for the
> > > systemd --user instance and the lack of either a policy workaround (as
> > > previously done in Fedora to limit outbound transitions from init_t to
> > > only valid cases) or the recent libselinux fix (to stop using
> > > /sys/fs/selinux/user altogether).  To permit testing without requiring
> > > my own custom policy or libselinux, I simply ran the tests from a ssh
> > > login rather than a graphical login.  Non-graphical console login
> > > probably would have worked too but I didn't try. But I have escalated
> > > the bug with the Debian SELinux maintainers in hopes of getting that
> > > fixed.
> > >
> > > 2) In Debian unstable, I also had to setsebool -P ssh_sysadm_login=1
> > > to allow ssh login as unconfined.  I let the Debian SELinux
> > > maintainers know but it isn't clear they will change the default.
> > >
> > > 3) Debian policy package ships with /etc/selinux/config set to
> > > permissive since the policy often doesn't work cleanly out of the box,
> > > so I had to manually setenforce 1 before running the testsuite.  This
> > > btw killed any gdm login sessions as well due to missing execmem and
> > > other permissions so that's another reason to not do it from a gdm
> > > login under their current policy.
> > >
> > > 4) The Debian stable kernel didn't enable CONFIG_NETLABEL so all of
> > > the netlabel-dependent inet_socket tests failed on stable.  Debian
> > > unstable kernel had CONFIG_NETLABEL enabled and they all passed there.
> > > I didn't consider it worthwhile to build my own Debian stable kernel
> > > for testing it; I just wanted to ensure that the policy worked, which
> > > I consider the Debian unstable test to prove.
> > >
> > > Interestingly, on Debian unstable, we end up running more tests than
> > > on Fedora rawhide currently: 64 test scripts with 869 individual tests
> > > versus 62 test scripts with 824 individual tests.  This is because
> > > Debian unstable's policy (which is based on a recent snapshot of
> > > refpolicy) has class and permission definitions for everything in its
> > > kernel except the lockdown class, versus Fedora which lacks the watch*
> > > permissions as well as the perf_event and lockdown classes.
> >
> > This is fantastic, I haven't looked at it fully yet. But I'm assuming this would
> > be the initial bulk work to get the make check on travis better. So in theory
> > we can just replicate this on Travis. Is my understanding correct here?
> > Ideally, we can get to a point where if CI is passing, its already an RC
> > candidate.
>
> That would be great but I don't think it is quite that easy
> unfortunately. I'm not a travis-ci expert by any means, but I don't
> think it provides us with a way to replicate the current steps
> required to enable SELinux in Debian or Ubuntu.  Debian's current
> approach to enabling SELinux involves installing some additional
> packages, running a selinux-activate script to modify the kernel
> command line in the grub configuration to enable SELinux in the kernel
> and to update some other configurations (e.g. adding pam_selinux to
> pam configs), rebooting to come up with SELinux enabled in the kernel
> and to label all filesystems, and rebooting a second time to come up
> with everything including init in the right SELinux domain.  In
> contrast I think travis-ci just provides you with a stock Ubuntu LTS
> image and allows you to install additional packages and run commands
> on that running instance, but not to specify custom kernel parameters
> initially or to reboot the system before proceeding with further
> commands (if anyone knows differently, speak up). We'd have to get to
> the point where enabling SELinux in Debian is possible without
> requiring a reboot at all.  And then we'd have to wait for that
> support to find its way into one of the Ubuntu images supported by
> travis-ci.  Might be easier to just get travis-ci to support Fedora or
> CentOS images in the first place. Regardless, allowing the testsuite
> to be run by users of other distributions is worthwhile IMHO.

Oh dang. I was hoping just root access would be enough. We could,
always start a VM
with Fedora on the Travis CI machine.... It would be heavy... but its
doable. Getting
travis to move their images to non-ancient things has seemed
impossible, and then them
picking Ubuntu helps keep packages outdated :-P. I might also want to
see what we can
do for other CI options.

My approach for getting our CI in a state where we can just release
off of master if CI is
passing, was a VM + Fedora.

Re: [PATCH] selinux-testsuite: update to work on Debian

[Russell Coker]

On Thursday, 7 May 2020 1:50:46 AM AEST Stephen Smalley wrote:
> on that running instance, but not to specify custom kernel parameters
> initially or to reboot the system before proceeding with further
> commands (if anyone knows differently, speak up). We'd have to get to
> the point where enabling SELinux in Debian is possible without
> requiring a reboot at all.  And then we'd have to wait for that
> support to find its way into one of the Ubuntu images supported by
> travis-ci.  Might be easier to just get travis-ci to support Fedora or
> CentOS images in the first place. Regardless, allowing the testsuite
> to be run by users of other distributions is worthwhile IMHO.

In the past there hasn't been much demand for a smoother installation process.  
If you are setting up a traditional Unix server system the Debian SE Linux 
installation thing doesn't make things much more difficult.  Past complaints 
about it have been more about an imagined difficulty of using SE Linux and have 
ended when I showed and wrote about how to do it (one time I showed 
screenshots of the process in an LCA lightning talk and didn't have problems 
with time).

I don't think that the people who maintain the Debian installation related 
packages would have a great objection to adding SE Linux features, although it 
might take a bit of time for it to migrate from Debian to Ubuntu.

We can make this a priority.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: [PATCH] selinux-testsuite: update to work on Debian

[Laurent Bigonville]

Le 6/05/20 à 18:37, Russell Coker a écrit :
> On Thursday, 7 May 2020 1:50:46 AM AEST Stephen Smalley wrote:
>> on that running instance, but not to specify custom kernel parameters
>> initially or to reboot the system before proceeding with further
>> commands (if anyone knows differently, speak up). We'd have to get to
>> the point where enabling SELinux in Debian is possible without
>> requiring a reboot at all.  And then we'd have to wait for that
>> support to find its way into one of the Ubuntu images supported by
>> travis-ci.  Might be easier to just get travis-ci to support Fedora or
>> CentOS images in the first place. Regardless, allowing the testsuite
>> to be run by users of other distributions is worthwhile IMHO.
> In the past there hasn't been much demand for a smoother installation process.
> If you are setting up a traditional Unix server system the Debian SE Linux
> installation thing doesn't make things much more difficult.  Past complaints
> about it have been more about an imagined difficulty of using SE Linux and have
> ended when I showed and wrote about how to do it (one time I showed
> screenshots of the process in an LCA lightning talk and didn't have problems
> with time).
>
> I don't think that the people who maintain the Debian installation related
> packages would have a great objection to adding SE Linux features, although it
> might take a bit of time for it to migrate from Debian to Ubuntu.
>
> We can make this a priority.
>
If people are using preseed installations (kickstart equivalent), I 
think that enabling SELinux in the installer shouldn't be too difficult 
(installing the needed packages, modifying the files and relabeling with 
fixfiles). It's obviously not user friendly, but the question is what's 
the target here.

Re: [PATCH] selinux-testsuite: update to work on Debian

[Stephen Smalley]

On Thu, May 7, 2020 at 4:46 AM Laurent Bigonville <bigon@debian.org> wrote:
>
> Le 6/05/20 à 18:37, Russell Coker a écrit :
> > On Thursday, 7 May 2020 1:50:46 AM AEST Stephen Smalley wrote:
> >> on that running instance, but not to specify custom kernel parameters
> >> initially or to reboot the system before proceeding with further
> >> commands (if anyone knows differently, speak up). We'd have to get to
> >> the point where enabling SELinux in Debian is possible without
> >> requiring a reboot at all.  And then we'd have to wait for that
> >> support to find its way into one of the Ubuntu images supported by
> >> travis-ci.  Might be easier to just get travis-ci to support Fedora or
> >> CentOS images in the first place. Regardless, allowing the testsuite
> >> to be run by users of other distributions is worthwhile IMHO.
> > In the past there hasn't been much demand for a smoother installation process.
> > If you are setting up a traditional Unix server system the Debian SE Linux
> > installation thing doesn't make things much more difficult.  Past complaints
> > about it have been more about an imagined difficulty of using SE Linux and have
> > ended when I showed and wrote about how to do it (one time I showed
> > screenshots of the process in an LCA lightning talk and didn't have problems
> > with time).
> >
> > I don't think that the people who maintain the Debian installation related
> > packages would have a great objection to adding SE Linux features, although it
> > might take a bit of time for it to migrate from Debian to Ubuntu.
> >
> > We can make this a priority.
> >
> If people are using preseed installations (kickstart equivalent), I
> think that enabling SELinux in the installer shouldn't be too difficult
> (installing the needed packages, modifying the files and relabeling with
> fixfiles). It's obviously not user friendly, but the question is what's
> the target here.

The visionary end state goal would be to allow one to specify some
kind of option in a travis-ci configuration and get a SELinux-enabled
image on which we could perform travis-ci validation of
selinux-testsuite, selinux userspace, and maybe even the kernel.  I
don't think that is possible in the near term though and will require
changes to travis-ci itself.  At the moment our travis-ci validation
of the testsuite and userspace is limited to building and in the
latter case running some limited tests that do not depend on having
SELinux on the host.

The nearer term goal is to minimize obstacles to using SELinux in
Debian, one of which is the need to install Debian and then install
SELinux as a separate step (with two reboots along the way) rather
than an installer option.  We can't use that approach in travis-ci
AFAICT because we cannot reboot the instance and then proceed with
testing.  If we can tell the installer to include the necessary grub
and pam configurations up front and to label the filesystems during
installation (which can happen even while SELinux is disabled in the
kernel; only requires filesystem xattr support), then we can avoid the
need for any extra reboots post install.

Re: [PATCH] selinux-testsuite: update to work on Debian

[Petr Lautrbach]

[-- Attachment #1: Type: text/plain, Size: 4443 bytes --]

On Thu, May 07, 2020 at 08:51:59AM -0400, Stephen Smalley wrote:
> On Thu, May 7, 2020 at 4:46 AM Laurent Bigonville <bigon@debian.org> wrote:
> >
> > Le 6/05/20 à 18:37, Russell Coker a écrit :
> > > On Thursday, 7 May 2020 1:50:46 AM AEST Stephen Smalley wrote:
> > >> on that running instance, but not to specify custom kernel parameters
> > >> initially or to reboot the system before proceeding with further
> > >> commands (if anyone knows differently, speak up). We'd have to get to
> > >> the point where enabling SELinux in Debian is possible without
> > >> requiring a reboot at all.  And then we'd have to wait for that
> > >> support to find its way into one of the Ubuntu images supported by
> > >> travis-ci.  Might be easier to just get travis-ci to support Fedora or
> > >> CentOS images in the first place. Regardless, allowing the testsuite
> > >> to be run by users of other distributions is worthwhile IMHO.
> > > In the past there hasn't been much demand for a smoother installation process.
> > > If you are setting up a traditional Unix server system the Debian SE Linux
> > > installation thing doesn't make things much more difficult.  Past complaints
> > > about it have been more about an imagined difficulty of using SE Linux and have
> > > ended when I showed and wrote about how to do it (one time I showed
> > > screenshots of the process in an LCA lightning talk and didn't have problems
> > > with time).
> > >
> > > I don't think that the people who maintain the Debian installation related
> > > packages would have a great objection to adding SE Linux features, although it
> > > might take a bit of time for it to migrate from Debian to Ubuntu.
> > >
> > > We can make this a priority.
> > >
> > If people are using preseed installations (kickstart equivalent), I
> > think that enabling SELinux in the installer shouldn't be too difficult
> > (installing the needed packages, modifying the files and relabeling with
> > fixfiles). It's obviously not user friendly, but the question is what's
> > the target here.
> 
> The visionary end state goal would be to allow one to specify some
> kind of option in a travis-ci configuration and get a SELinux-enabled
> image on which we could perform travis-ci validation of
> selinux-testsuite, selinux userspace, and maybe even the kernel.  I
> don't think that is possible in the near term though and will require
> changes to travis-ci itself.  At the moment our travis-ci validation
> of the testsuite and userspace is limited to building and in the
> latter case running some limited tests that do not depend on having
> SELinux on the host.
> 
> The nearer term goal is to minimize obstacles to using SELinux in
> Debian, one of which is the need to install Debian and then install
> SELinux as a separate step (with two reboots along the way) rather
> than an installer option.  We can't use that approach in travis-ci
> AFAICT because we cannot reboot the instance and then proceed with
> testing.  If we can tell the installer to include the necessary grub
> and pam configurations up front and to label the filesystems during
> installation (which can happen even while SELinux is disabled in the
> kernel; only requires filesystem xattr support), then we can avoid the
> need for any extra reboots post install.
> 

I'm experimenting with using Fedora CI for this, see https://src.fedoraproject.org/rpms/policycoreutils/pull-request/15

It uses Fedora Rawhide images and runs
https://src.fedoraproject.org/fork/plautrba/rpms/policycoreutils/blob/a9622b610a0f7cfb968d4cb216c9c5c42e87b6dd/f/tests/upstream/runtest.sh
script which is part of this PR


You can see a failure in Fedora CI:
https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-pr-pipeline/detail/fedora-rawhide-pr-pipeline/3441/pipeline/
-> Artifacts -> package-tests/logs/FAIL-upstream.log -
https://jenkins-continuous-infra.apps.ci.centos.org/job/fedora-rawhide-pr-pipeline/3441/artifact/package-tests/logs/FAIL-upstream.log

So far there's only userspace build and tests but it can be used for
selinux-testsuite and (Fedora) kernel.

It has one downside, it can be triggered only by a pull request on https://src.fedoraproject.org/rpms/policycoreutils

Petr
-- 
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] selinux-testsuite: update to work on Debian

[Stephen Smalley]

On Thu, May 7, 2020 at 9:13 AM Petr Lautrbach <plautrba@redhat.com> wrote:
>
> On Thu, May 07, 2020 at 08:51:59AM -0400, Stephen Smalley wrote:
> > On Thu, May 7, 2020 at 4:46 AM Laurent Bigonville <bigon@debian.org> wrote:
> > >
> > > Le 6/05/20 à 18:37, Russell Coker a écrit :
> > > > On Thursday, 7 May 2020 1:50:46 AM AEST Stephen Smalley wrote:
> > > >> on that running instance, but not to specify custom kernel parameters
> > > >> initially or to reboot the system before proceeding with further
> > > >> commands (if anyone knows differently, speak up). We'd have to get to
> > > >> the point where enabling SELinux in Debian is possible without
> > > >> requiring a reboot at all.  And then we'd have to wait for that
> > > >> support to find its way into one of the Ubuntu images supported by
> > > >> travis-ci.  Might be easier to just get travis-ci to support Fedora or
> > > >> CentOS images in the first place. Regardless, allowing the testsuite
> > > >> to be run by users of other distributions is worthwhile IMHO.
> > > > In the past there hasn't been much demand for a smoother installation process.
> > > > If you are setting up a traditional Unix server system the Debian SE Linux
> > > > installation thing doesn't make things much more difficult.  Past complaints
> > > > about it have been more about an imagined difficulty of using SE Linux and have
> > > > ended when I showed and wrote about how to do it (one time I showed
> > > > screenshots of the process in an LCA lightning talk and didn't have problems
> > > > with time).
> > > >
> > > > I don't think that the people who maintain the Debian installation related
> > > > packages would have a great objection to adding SE Linux features, although it
> > > > might take a bit of time for it to migrate from Debian to Ubuntu.
> > > >
> > > > We can make this a priority.
> > > >
> > > If people are using preseed installations (kickstart equivalent), I
> > > think that enabling SELinux in the installer shouldn't be too difficult
> > > (installing the needed packages, modifying the files and relabeling with
> > > fixfiles). It's obviously not user friendly, but the question is what's
> > > the target here.
> >
> > The visionary end state goal would be to allow one to specify some
> > kind of option in a travis-ci configuration and get a SELinux-enabled
> > image on which we could perform travis-ci validation of
> > selinux-testsuite, selinux userspace, and maybe even the kernel.  I
> > don't think that is possible in the near term though and will require
> > changes to travis-ci itself.  At the moment our travis-ci validation
> > of the testsuite and userspace is limited to building and in the
> > latter case running some limited tests that do not depend on having
> > SELinux on the host.
> >
> > The nearer term goal is to minimize obstacles to using SELinux in
> > Debian, one of which is the need to install Debian and then install
> > SELinux as a separate step (with two reboots along the way) rather
> > than an installer option.  We can't use that approach in travis-ci
> > AFAICT because we cannot reboot the instance and then proceed with
> > testing.  If we can tell the installer to include the necessary grub
> > and pam configurations up front and to label the filesystems during
> > installation (which can happen even while SELinux is disabled in the
> > kernel; only requires filesystem xattr support), then we can avoid the
> > need for any extra reboots post install.
> >
>
> I'm experimenting with using Fedora CI for this, see https://src.fedoraproject.org/rpms/policycoreutils/pull-request/15
>
> It uses Fedora Rawhide images and runs
> https://src.fedoraproject.org/fork/plautrba/rpms/policycoreutils/blob/a9622b610a0f7cfb968d4cb216c9c5c42e87b6dd/f/tests/upstream/runtest.sh
> script which is part of this PR
>
>
> You can see a failure in Fedora CI:
> https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-pr-pipeline/detail/fedora-rawhide-pr-pipeline/3441/pipeline/
> -> Artifacts -> package-tests/logs/FAIL-upstream.log -
> https://jenkins-continuous-infra.apps.ci.centos.org/job/fedora-rawhide-pr-pipeline/3441/artifact/package-tests/logs/FAIL-upstream.log
>
> So far there's only userspace build and tests but it can be used for
> selinux-testsuite and (Fedora) kernel.
>
> It has one downside, it can be triggered only by a pull request on https://src.fedoraproject.org/rpms/policycoreutils

Interesting, thanks.  Regrettably the make test cases in the userspace
tree are fairly limited (and can't be too extensive if they are going
to keep working on travis-ci since they cannot presume SELinux in the
host).  In practice, I usually also test changes to the userspace by
running the selinux-testsuite, which exercises rebuilding policy and
confirms various runtime behaviors that are not exercised by the
userspace make test, and by rebuilding refpolicy (or Fedora policy
would also work) and comparing against what the previous version
yielded.  We also likely ought to be re-testing setools upon changes
to the userspace and vice versa.  They are all rather intertwined.

Re: [PATCH] selinux-testsuite: update to work on Debian

[Laurent Bigonville]

Le 7/05/20 à 14:51, Stephen Smalley a écrit :
> On Thu, May 7, 2020 at 4:46 AM Laurent Bigonville <bigon@debian.org> wrote:
>> Le 6/05/20 à 18:37, Russell Coker a écrit :
>>> On Thursday, 7 May 2020 1:50:46 AM AEST Stephen Smalley wrote:
>>>> on that running instance, but not to specify custom kernel parameters
>>>> initially or to reboot the system before proceeding with further
>>>> commands (if anyone knows differently, speak up). We'd have to get to
>>>> the point where enabling SELinux in Debian is possible without
>>>> requiring a reboot at all.  And then we'd have to wait for that
>>>> support to find its way into one of the Ubuntu images supported by
>>>> travis-ci.  Might be easier to just get travis-ci to support Fedora or
>>>> CentOS images in the first place. Regardless, allowing the testsuite
>>>> to be run by users of other distributions is worthwhile IMHO.
>>> In the past there hasn't been much demand for a smoother installation process.
>>> If you are setting up a traditional Unix server system the Debian SE Linux
>>> installation thing doesn't make things much more difficult.  Past complaints
>>> about it have been more about an imagined difficulty of using SE Linux and have
>>> ended when I showed and wrote about how to do it (one time I showed
>>> screenshots of the process in an LCA lightning talk and didn't have problems
>>> with time).
>>>
>>> I don't think that the people who maintain the Debian installation related
>>> packages would have a great objection to adding SE Linux features, although it
>>> might take a bit of time for it to migrate from Debian to Ubuntu.
>>>
>>> We can make this a priority.
>>>
>> If people are using preseed installations (kickstart equivalent), I
>> think that enabling SELinux in the installer shouldn't be too difficult
>> (installing the needed packages, modifying the files and relabeling with
>> fixfiles). It's obviously not user friendly, but the question is what's
>> the target here.
> The visionary end state goal would be to allow one to specify some
> kind of option in a travis-ci configuration and get a SELinux-enabled
> image on which we could perform travis-ci validation of
> selinux-testsuite, selinux userspace, and maybe even the kernel.  I
> don't think that is possible in the near term though and will require
> changes to travis-ci itself.  At the moment our travis-ci validation
> of the testsuite and userspace is limited to building and in the
> latter case running some limited tests that do not depend on having
> SELinux on the host.
>
> The nearer term goal is to minimize obstacles to using SELinux in
> Debian, one of which is the need to install Debian and then install
> SELinux as a separate step (with two reboots along the way) rather
> than an installer option.  We can't use that approach in travis-ci
> AFAICT because we cannot reboot the instance and then proceed with
> testing.  If we can tell the installer to include the necessary grub
> and pam configurations up front and to label the filesystems during
> installation (which can happen even while SELinux is disabled in the
> kernel; only requires filesystem xattr support), then we can avoid the
> need for any extra reboots post install.

FTR, the modifications to the PAM service files shouldn't be necessary 
anymore, all the necessary PAM services are calling pam_selinux for a 
few stable releases

Re: [PATCH] selinux-testsuite: update to work on Debian

[Paul Moore]

On Thu, May 7, 2020 at 8:52 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Thu, May 7, 2020 at 4:46 AM Laurent Bigonville <bigon@debian.org> wrote:
> >
> > Le 6/05/20 à 18:37, Russell Coker a écrit :
> > > On Thursday, 7 May 2020 1:50:46 AM AEST Stephen Smalley wrote:
> > >> on that running instance, but not to specify custom kernel parameters
> > >> initially or to reboot the system before proceeding with further
> > >> commands (if anyone knows differently, speak up). We'd have to get to
> > >> the point where enabling SELinux in Debian is possible without
> > >> requiring a reboot at all.  And then we'd have to wait for that
> > >> support to find its way into one of the Ubuntu images supported by
> > >> travis-ci.  Might be easier to just get travis-ci to support Fedora or
> > >> CentOS images in the first place. Regardless, allowing the testsuite
> > >> to be run by users of other distributions is worthwhile IMHO.
> > > In the past there hasn't been much demand for a smoother installation process.
> > > If you are setting up a traditional Unix server system the Debian SE Linux
> > > installation thing doesn't make things much more difficult.  Past complaints
> > > about it have been more about an imagined difficulty of using SE Linux and have
> > > ended when I showed and wrote about how to do it (one time I showed
> > > screenshots of the process in an LCA lightning talk and didn't have problems
> > > with time).
> > >
> > > I don't think that the people who maintain the Debian installation related
> > > packages would have a great objection to adding SE Linux features, although it
> > > might take a bit of time for it to migrate from Debian to Ubuntu.
> > >
> > > We can make this a priority.
> > >
> > If people are using preseed installations (kickstart equivalent), I
> > think that enabling SELinux in the installer shouldn't be too difficult
> > (installing the needed packages, modifying the files and relabeling with
> > fixfiles). It's obviously not user friendly, but the question is what's
> > the target here.
>
> The visionary end state goal would be to allow one to specify some
> kind of option in a travis-ci configuration and get a SELinux-enabled
> image on which we could perform travis-ci validation of
> selinux-testsuite, selinux userspace, and maybe even the kernel.  I
> don't think that is possible in the near term though and will require
> changes to travis-ci itself.  At the moment our travis-ci validation
> of the testsuite and userspace is limited to building and in the
> latter case running some limited tests that do not depend on having
> SELinux on the host.
>
> The nearer term goal is to minimize obstacles to using SELinux in
> Debian, one of which is the need to install Debian and then install
> SELinux as a separate step (with two reboots along the way) rather
> than an installer option.  We can't use that approach in travis-ci
> AFAICT because we cannot reboot the instance and then proceed with
> testing.  If we can tell the installer to include the necessary grub
> and pam configurations up front and to label the filesystems during
> installation (which can happen even while SELinux is disabled in the
> kernel; only requires filesystem xattr support), then we can avoid the
> need for any extra reboots post install.

For a long time now I've wanted to expand my selinux/next kernel
testing to platforms beyond Fedora.  I believe that it not only helps
catch problems before the kernel is released, but it also helps ensure
that the underlying distro has all of the necessary pieces (userspace,
policy, etc.) in place to support the latest and upcoming kernels.

Unfortunately every time I've looked at the state of SELinux in Debian
I've run out of time before I got it working well.  I'm not even going
to get into the Debian package format :/

I would be very happy to see some work go into lowering the bar on
getting SELinux working on Debian.  My Debian experience is pretty
limited, but you can sign me up as a very enthusiastic beta-tester,
just point me at some docs and an ISO :)

-- 
paul moore
www.paul-moore.com

Re: [PATCH] selinux-testsuite: update to work on Debian

[Stephen Smalley]

On Thu, May 7, 2020 at 11:03 PM Paul Moore <paul@paul-moore.com> wrote:
> For a long time now I've wanted to expand my selinux/next kernel
> testing to platforms beyond Fedora.  I believe that it not only helps
> catch problems before the kernel is released, but it also helps ensure
> that the underlying distro has all of the necessary pieces (userspace,
> policy, etc.) in place to support the latest and upcoming kernels.
>
> Unfortunately every time I've looked at the state of SELinux in Debian
> I've run out of time before I got it working well.  I'm not even going
> to get into the Debian package format :/
>
> I would be very happy to see some work go into lowering the bar on
> getting SELinux working on Debian.  My Debian experience is pretty
> limited, but you can sign me up as a very enthusiastic beta-tester,
> just point me at some docs and an ISO :)

FWIW, with the just-merged series, if you follow the new instructions
in the README.md for Debian, you should be able to successfully build
and run the testsuite on Debian stable and unstable (also worked for
me on Ubuntu 20.04 aside from needing to obtain libbpf from upstream
since it isn't packaged for Ubuntu).  The default policy still has
some issues (e.g. don't try to use GNOME in enforcing mode) but if you
can login as an unconfined user and setenforce 1 via text console or
ssh login, you should be able to run the testsuite.

Re: [PATCH] selinux-testsuite: update to work on Debian

[William Roberts]

On Wed, May 13, 2020 at 10:51 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, May 7, 2020 at 11:03 PM Paul Moore <paul@paul-moore.com> wrote:
> > For a long time now I've wanted to expand my selinux/next kernel
> > testing to platforms beyond Fedora.  I believe that it not only helps
> > catch problems before the kernel is released, but it also helps ensure
> > that the underlying distro has all of the necessary pieces (userspace,
> > policy, etc.) in place to support the latest and upcoming kernels.
> >
> > Unfortunately every time I've looked at the state of SELinux in Debian
> > I've run out of time before I got it working well.  I'm not even going
> > to get into the Debian package format :/
> >
> > I would be very happy to see some work go into lowering the bar on
> > getting SELinux working on Debian.  My Debian experience is pretty
> > limited, but you can sign me up as a very enthusiastic beta-tester,
> > just point me at some docs and an ISO :)
>
> FWIW, with the just-merged series, if you follow the new instructions
> in the README.md for Debian, you should be able to successfully build
> and run the testsuite on Debian stable and unstable (also worked for
> me on Ubuntu 20.04 aside from needing to obtain libbpf from upstream
> since it isn't packaged for Ubuntu).  The default policy still has
> some issues (e.g. don't try to use GNOME in enforcing mode) but if you
> can login as an unconfined user and setenforce 1 via text console or
> ssh login, you should be able to run the testsuite.

I am having an issue with the test suite, perhaps the error would be obvious
to you or someone else

Error:
make[3]: Entering directory '/root/selinux-testsuite/tests/module_load'
make[3]: *** /lib/modules/5.6.6-300.fc32.x86_64/build: No such file or
directory.  Stop.
make[3]: Leaving directory '/root/selinux-testsuite/tests/module_load'
make[2]: *** [Makefile:8: all] Error 2
make[2]: Leaving directory '/root/selinux-testsuite/tests/module_load'
make[1]: *** [Makefile:141: all] Error 1
make[1]: Leaving directory '/root/selinux-testsuite/tests'
make: *** [Makefile:8: test] Error 2

The module_load path exists:
[root@demo tests]# ls /lib/modules/5.6.6-300.fc32.x86_64/
bls.conf    modules.builtin       modules.drm    source
build    modules.builtin.alias.bin  modules.modesetting  symvers.gz
config    modules.builtin.bin       modules.networking   System.map
kernel    modules.builtin.modinfo    modules.order    updates
modules.alias    modules.dep       modules.softdep    vdso
modules.alias.bin  modules.dep.bin       modules.symbols    vmlinuz
modules.block    modules.devname       modules.symbols.bin

And build exists, but it's a file, is that right?
[root@demo tests]# stat /lib/modules/5.6.6-300.fc32.x86_64/build
  File: /lib/modules/5.6.6-300.fc32.x86_64/build ->
/usr/src/kernels/5.6.6-300.fc32.x86_64
  Size: 38        Blocks: 0          IO Block: 4096   symbolic link
Device: 801h/2049d Inode: 154128      Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:modules_object_t:s0
Access: 2020-05-15 16:23:03.854826122 +0000
Modify: 2020-04-21 14:01:58.000000000 +0000
Change: 2020-04-22 22:30:37.051096556 +0000
 Birth: -

Thanks,
Bill

Re: [PATCH] selinux-testsuite: update to work on Debian

[Ondrej Mosnacek]

On Fri, May 15, 2020 at 6:27 PM William Roberts
<bill.c.roberts@gmail.com> wrote:
> I am having an issue with the test suite, perhaps the error would be obvious
> to you or someone else
>
> Error:
> make[3]: Entering directory '/root/selinux-testsuite/tests/module_load'
> make[3]: *** /lib/modules/5.6.6-300.fc32.x86_64/build: No such file or
> directory.  Stop.
> make[3]: Leaving directory '/root/selinux-testsuite/tests/module_load'
> make[2]: *** [Makefile:8: all] Error 2
> make[2]: Leaving directory '/root/selinux-testsuite/tests/module_load'
> make[1]: *** [Makefile:141: all] Error 1
> make[1]: Leaving directory '/root/selinux-testsuite/tests'
> make: *** [Makefile:8: test] Error 2
>
> The module_load path exists:
> [root@demo tests]# ls /lib/modules/5.6.6-300.fc32.x86_64/
> bls.conf    modules.builtin       modules.drm    source
> build    modules.builtin.alias.bin  modules.modesetting  symvers.gz
> config    modules.builtin.bin       modules.networking   System.map
> kernel    modules.builtin.modinfo    modules.order    updates
> modules.alias    modules.dep       modules.softdep    vdso
> modules.alias.bin  modules.dep.bin       modules.symbols    vmlinuz
> modules.block    modules.devname       modules.symbols.bin
>
> And build exists, but it's a file, is that right?
> [root@demo tests]# stat /lib/modules/5.6.6-300.fc32.x86_64/build
>   File: /lib/modules/5.6.6-300.fc32.x86_64/build ->
> /usr/src/kernels/5.6.6-300.fc32.x86_64
>   Size: 38        Blocks: 0          IO Block: 4096   symbolic link
> Device: 801h/2049d Inode: 154128      Links: 1
> Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
> Context: system_u:object_r:modules_object_t:s0
> Access: 2020-05-15 16:23:03.854826122 +0000
> Modify: 2020-04-21 14:01:58.000000000 +0000
> Change: 2020-04-22 22:30:37.051096556 +0000
>  Birth: -

It is a symlink, as evident from the stat output above, which is
normal. You probably just don't have the matching kernel-devel package
installed, so the target directory (/usr/src/...) doesn't exist.

-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.

Re: [PATCH] selinux-testsuite: update to work on Debian

[William Roberts]

On Fri, May 15, 2020 at 11:41 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> On Fri, May 15, 2020 at 6:27 PM William Roberts
> <bill.c.roberts@gmail.com> wrote:
> > I am having an issue with the test suite, perhaps the error would be obvious
> > to you or someone else
> >
> > Error:
> > make[3]: Entering directory '/root/selinux-testsuite/tests/module_load'
> > make[3]: *** /lib/modules/5.6.6-300.fc32.x86_64/build: No such file or
> > directory.  Stop.
> > make[3]: Leaving directory '/root/selinux-testsuite/tests/module_load'
> > make[2]: *** [Makefile:8: all] Error 2
> > make[2]: Leaving directory '/root/selinux-testsuite/tests/module_load'
> > make[1]: *** [Makefile:141: all] Error 1
> > make[1]: Leaving directory '/root/selinux-testsuite/tests'
> > make: *** [Makefile:8: test] Error 2
> >
> > The module_load path exists:
> > [root@demo tests]# ls /lib/modules/5.6.6-300.fc32.x86_64/
> > bls.conf    modules.builtin       modules.drm    source
> > build    modules.builtin.alias.bin  modules.modesetting  symvers.gz
> > config    modules.builtin.bin       modules.networking   System.map
> > kernel    modules.builtin.modinfo    modules.order    updates
> > modules.alias    modules.dep       modules.softdep    vdso
> > modules.alias.bin  modules.dep.bin       modules.symbols    vmlinuz
> > modules.block    modules.devname       modules.symbols.bin
> >
> > And build exists, but it's a file, is that right?
> > [root@demo tests]# stat /lib/modules/5.6.6-300.fc32.x86_64/build
> >   File: /lib/modules/5.6.6-300.fc32.x86_64/build ->
> > /usr/src/kernels/5.6.6-300.fc32.x86_64
> >   Size: 38        Blocks: 0          IO Block: 4096   symbolic link
> > Device: 801h/2049d Inode: 154128      Links: 1
> > Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
> > Context: system_u:object_r:modules_object_t:s0
> > Access: 2020-05-15 16:23:03.854826122 +0000
> > Modify: 2020-04-21 14:01:58.000000000 +0000
> > Change: 2020-04-22 22:30:37.051096556 +0000
> >  Birth: -
>
> It is a symlink, as evident from the stat output above, which is

very evident, how did I not notice that... (face palm)

> normal. You probably just don't have the matching kernel-devel package
> installed, so the target directory (/usr/src/...) doesn't exist.

It seems installed:
full logs here:
https://travis-ci.org/github/williamcroberts/selinux/builds/687514828

I ran this on my local VM in same error state:
# dnf install -y kernel-devel
Last metadata expiration check: 0:39:22 ago on Fri 15 May 2020 04:05:19 PM UTC.
Package kernel-devel-5.6.12-300.fc32.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

Should we add this to the dnf command in the README?:
https://github.com/SELinuxProject/selinux-testsuite

>
> --
> Ondrej Mosnacek <omosnace at redhat dot com>
> Software Engineer, Security Technologies
> Red Hat, Inc.
>

Re: [PATCH] selinux-testsuite: update to work on Debian

[Ondrej Mosnacek]

On Fri, May 15, 2020 at 6:47 PM William Roberts
<bill.c.roberts@gmail.com> wrote:
> On Fri, May 15, 2020 at 11:41 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> >
> > On Fri, May 15, 2020 at 6:27 PM William Roberts
> > <bill.c.roberts@gmail.com> wrote:
> > > I am having an issue with the test suite, perhaps the error would be obvious
> > > to you or someone else
> > >
> > > Error:
> > > make[3]: Entering directory '/root/selinux-testsuite/tests/module_load'
> > > make[3]: *** /lib/modules/5.6.6-300.fc32.x86_64/build: No such file or
> > > directory.  Stop.
> > > make[3]: Leaving directory '/root/selinux-testsuite/tests/module_load'
> > > make[2]: *** [Makefile:8: all] Error 2
> > > make[2]: Leaving directory '/root/selinux-testsuite/tests/module_load'
> > > make[1]: *** [Makefile:141: all] Error 1
> > > make[1]: Leaving directory '/root/selinux-testsuite/tests'
> > > make: *** [Makefile:8: test] Error 2
> > >
> > > The module_load path exists:
> > > [root@demo tests]# ls /lib/modules/5.6.6-300.fc32.x86_64/
> > > bls.conf    modules.builtin       modules.drm    source
> > > build    modules.builtin.alias.bin  modules.modesetting  symvers.gz
> > > config    modules.builtin.bin       modules.networking   System.map
> > > kernel    modules.builtin.modinfo    modules.order    updates
> > > modules.alias    modules.dep       modules.softdep    vdso
> > > modules.alias.bin  modules.dep.bin       modules.symbols    vmlinuz
> > > modules.block    modules.devname       modules.symbols.bin
> > >
> > > And build exists, but it's a file, is that right?
> > > [root@demo tests]# stat /lib/modules/5.6.6-300.fc32.x86_64/build
> > >   File: /lib/modules/5.6.6-300.fc32.x86_64/build ->
> > > /usr/src/kernels/5.6.6-300.fc32.x86_64
> > >   Size: 38        Blocks: 0          IO Block: 4096   symbolic link
> > > Device: 801h/2049d Inode: 154128      Links: 1
> > > Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
> > > Context: system_u:object_r:modules_object_t:s0
> > > Access: 2020-05-15 16:23:03.854826122 +0000
> > > Modify: 2020-04-21 14:01:58.000000000 +0000
> > > Change: 2020-04-22 22:30:37.051096556 +0000
> > >  Birth: -
> >
> > It is a symlink, as evident from the stat output above, which is
>
> very evident, how did I not notice that... (face palm)
>
> > normal. You probably just don't have the matching kernel-devel package
> > installed, so the target directory (/usr/src/...) doesn't exist.
>
> It seems installed:

There is a subtle catch :) You need to have the exact version that
matches your $(uname -r). In your case it seems to be
5.6.6-300.fc32.x86_64, while you probably only have the latest version
of kernel-devel (5.6.12-300.fc32.x86_64). Try:

dnf install -y kernel-devel-$(uname -r)

Note that this may fail if the corresponding version is no longer in
the repos (5.6.12 >> 5.6.6, so it will probably fail in your case). In
that case you need to reboot the VM so that you run under the latest
installed kernel, for which you have kernel-devel.

> full logs here:
> https://travis-ci.org/github/williamcroberts/selinux/builds/687514828
>
> I ran this on my local VM in same error state:
> # dnf install -y kernel-devel
> Last metadata expiration check: 0:39:22 ago on Fri 15 May 2020 04:05:19 PM UTC.
> Package kernel-devel-5.6.12-300.fc32.x86_64 is already installed.
> Dependencies resolved.
> Nothing to do.
> Complete!
>
> Should we add this to the dnf command in the README?:
> https://github.com/SELinuxProject/selinux-testsuite

-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.

Re: [PATCH] selinux-testsuite: update to work on Debian

[William Roberts]

On Fri, May 15, 2020 at 12:18 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> On Fri, May 15, 2020 at 6:47 PM William Roberts
> <bill.c.roberts@gmail.com> wrote:
> > On Fri, May 15, 2020 at 11:41 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > >
> > > On Fri, May 15, 2020 at 6:27 PM William Roberts
> > > <bill.c.roberts@gmail.com> wrote:
> > > > I am having an issue with the test suite, perhaps the error would be obvious
> > > > to you or someone else
> > > >
> > > > Error:
> > > > make[3]: Entering directory '/root/selinux-testsuite/tests/module_load'
> > > > make[3]: *** /lib/modules/5.6.6-300.fc32.x86_64/build: No such file or
> > > > directory.  Stop.
> > > > make[3]: Leaving directory '/root/selinux-testsuite/tests/module_load'
> > > > make[2]: *** [Makefile:8: all] Error 2
> > > > make[2]: Leaving directory '/root/selinux-testsuite/tests/module_load'
> > > > make[1]: *** [Makefile:141: all] Error 1
> > > > make[1]: Leaving directory '/root/selinux-testsuite/tests'
> > > > make: *** [Makefile:8: test] Error 2
> > > >
> > > > The module_load path exists:
> > > > [root@demo tests]# ls /lib/modules/5.6.6-300.fc32.x86_64/
> > > > bls.conf    modules.builtin       modules.drm    source
> > > > build    modules.builtin.alias.bin  modules.modesetting  symvers.gz
> > > > config    modules.builtin.bin       modules.networking   System.map
> > > > kernel    modules.builtin.modinfo    modules.order    updates
> > > > modules.alias    modules.dep       modules.softdep    vdso
> > > > modules.alias.bin  modules.dep.bin       modules.symbols    vmlinuz
> > > > modules.block    modules.devname       modules.symbols.bin
> > > >
> > > > And build exists, but it's a file, is that right?
> > > > [root@demo tests]# stat /lib/modules/5.6.6-300.fc32.x86_64/build
> > > >   File: /lib/modules/5.6.6-300.fc32.x86_64/build ->
> > > > /usr/src/kernels/5.6.6-300.fc32.x86_64
> > > >   Size: 38        Blocks: 0          IO Block: 4096   symbolic link
> > > > Device: 801h/2049d Inode: 154128      Links: 1
> > > > Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
> > > > Context: system_u:object_r:modules_object_t:s0
> > > > Access: 2020-05-15 16:23:03.854826122 +0000
> > > > Modify: 2020-04-21 14:01:58.000000000 +0000
> > > > Change: 2020-04-22 22:30:37.051096556 +0000
> > > >  Birth: -
> > >
> > > It is a symlink, as evident from the stat output above, which is
> >
> > very evident, how did I not notice that... (face palm)
> >
> > > normal. You probably just don't have the matching kernel-devel package
> > > installed, so the target directory (/usr/src/...) doesn't exist.
> >
> > It seems installed:
>
> There is a subtle catch :) You need to have the exact version that
> matches your $(uname -r). In your case it seems to be
> 5.6.6-300.fc32.x86_64, while you probably only have the latest version
> of kernel-devel (5.6.12-300.fc32.x86_64). Try:
>
> dnf install -y kernel-devel-$(uname -r)

That actually worked as is and the test suite is running, a few things have
failed, but another step in the right direction.

>
> Note that this may fail if the corresponding version is no longer in
> the repos (5.6.12 >> 5.6.6, so it will probably fail in your case). In
> that case you need to reboot the VM so that you run under the latest
> installed kernel, for which you have kernel-devel.
>
> > full logs here:
> > https://travis-ci.org/github/williamcroberts/selinux/builds/687514828
> >
> > I ran this on my local VM in same error state:
> > # dnf install -y kernel-devel
> > Last metadata expiration check: 0:39:22 ago on Fri 15 May 2020 04:05:19 PM UTC.
> > Package kernel-devel-5.6.12-300.fc32.x86_64 is already installed.
> > Dependencies resolved.
> > Nothing to do.
> > Complete!
> >
> > Should we add this to the dnf command in the README?:
> > https://github.com/SELinuxProject/selinux-testsuite
>
> --
> Ondrej Mosnacek <omosnace at redhat dot com>
> Software Engineer, Security Technologies
> Red Hat, Inc.
>

Re: [PATCH] selinux-testsuite: update to work on Debian

[Russell Coker]

On Thursday, 7 May 2020 6:35:11 PM AEST Laurent Bigonville wrote:
> If people are using preseed installations (kickstart equivalent), I
> think that enabling SELinux in the installer shouldn't be too difficult
> (installing the needed packages, modifying the files and relabeling with
> fixfiles). It's obviously not user friendly, but the question is what's
> the target here.

If we want to do that properly then I guess we want SE Linux enabled in the 
kernel that the installer uses and then have the policy installed early in the 
installation so the files can have the correct labels from the start instead of 
having a relabel process afterwards.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: [PATCH] selinux-testsuite: update to work on Debian

[Stephen Smalley]

On Thu, May 7, 2020 at 10:49 AM Russell Coker <russell@coker.com.au> wrote:
>
> On Thursday, 7 May 2020 6:35:11 PM AEST Laurent Bigonville wrote:
> > If people are using preseed installations (kickstart equivalent), I
> > think that enabling SELinux in the installer shouldn't be too difficult
> > (installing the needed packages, modifying the files and relabeling with
> > fixfiles). It's obviously not user friendly, but the question is what's
> > the target here.
>
> If we want to do that properly then I guess we want SE Linux enabled in the
> kernel that the installer uses and then have the policy installed early in the
> installation so the files can have the correct labels from the start instead of
> having a relabel process afterwards.

That would be good but might be overreach for Debian since SELinux is
not the default there.  It isn't strictly necessary; ever since we
went to using extended attributes for file labels, you can set them on
a non-SELinux-enabled kernel, so the installer can always set them
even if its kernel doesn't enable SELinux.  Optimally they would be
set by the package manager based on file_contexts; that is what rpm
does in Fedora/RHEL.  Or you can always run setfiles after package
installation but before rebooting into the SELinux-enabled kernel.
You don't need to defer labeling until you have SELinux enabled.

Re: [PATCH] selinux-testsuite: update to work on Debian

[William Roberts]

>
> On Thu, May 7, 2020 at 10:49 AM Russell Coker <russell@coker.com.au> wrote:
> >
> > On Thursday, 7 May 2020 6:35:11 PM AEST Laurent Bigonville wrote:
> > > If people are using preseed installations (kickstart equivalent), I
> > > think that enabling SELinux in the installer shouldn't be too difficult
> > > (installing the needed packages, modifying the files and relabeling with
> > > fixfiles). It's obviously not user friendly, but the question is what's
> > > the target here.
> >
> > If we want to do that properly then I guess we want SE Linux enabled in the
> > kernel that the installer uses and then have the policy installed early in the
> > installation so the files can have the correct labels from the start instead of
> > having a relabel process afterwards.
>
> That would be good but might be overreach for Debian since SELinux is
> not the default there.  It isn't strictly necessary; ever since we
> went to using extended attributes for file labels, you can set them on
> a non-SELinux-enabled kernel, so the installer can always set them
> even if its kernel doesn't enable SELinux.  Optimally they would be
> set by the package manager based on file_contexts; that is what rpm
> does in Fedora/RHEL.  Or you can always run setfiles after package
> installation but before rebooting into the SELinux-enabled kernel.
> You don't need to defer labeling until you have SELinux enabled.

On Thu, May 7, 2020 at 9:54 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:

I found this:
  - https://man.sr.ht/builds.sr.ht/compatibility.md

It seems to have Fedora-30,31 and rawhide.
It seems to be free as well (for now)
I would be a little leary using it, seems new, its only in alpha,
and looks like it could disappear at any moment.

The travis ubuntu to fedora VM might be heavy, but it would at least provide
us with something stable... for awhile or we look at getting some
better infrastructure support for running a CI job on.

Re: [PATCH] selinux-testsuite: update to work on Debian

[Stephen Smalley]

On Thu, May 7, 2020 at 11:02 AM William Roberts
<bill.c.roberts@gmail.com> wrote:
>
> >
> > On Thu, May 7, 2020 at 10:49 AM Russell Coker <russell@coker.com.au> wrote:
> > >
> > > On Thursday, 7 May 2020 6:35:11 PM AEST Laurent Bigonville wrote:
> > > > If people are using preseed installations (kickstart equivalent), I
> > > > think that enabling SELinux in the installer shouldn't be too difficult
> > > > (installing the needed packages, modifying the files and relabeling with
> > > > fixfiles). It's obviously not user friendly, but the question is what's
> > > > the target here.
> > >
> > > If we want to do that properly then I guess we want SE Linux enabled in the
> > > kernel that the installer uses and then have the policy installed early in the
> > > installation so the files can have the correct labels from the start instead of
> > > having a relabel process afterwards.
> >
> > That would be good but might be overreach for Debian since SELinux is
> > not the default there.  It isn't strictly necessary; ever since we
> > went to using extended attributes for file labels, you can set them on
> > a non-SELinux-enabled kernel, so the installer can always set them
> > even if its kernel doesn't enable SELinux.  Optimally they would be
> > set by the package manager based on file_contexts; that is what rpm
> > does in Fedora/RHEL.  Or you can always run setfiles after package
> > installation but before rebooting into the SELinux-enabled kernel.
> > You don't need to defer labeling until you have SELinux enabled.
>
> On Thu, May 7, 2020 at 9:54 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
>
> I found this:
>   - https://man.sr.ht/builds.sr.ht/compatibility.md
>
> It seems to have Fedora-30,31 and rawhide.
> It seems to be free as well (for now)
> I would be a little leary using it, seems new, its only in alpha,
> and looks like it could disappear at any moment.
>
> The travis ubuntu to fedora VM might be heavy, but it would at least provide
> us with something stable... for awhile or we look at getting some
> better infrastructure support for running a CI job on.

Fedora's own CI infrastructure seems like a better bet for the near
term wrt testing on Fedora; Petr appears to be already exploring using
it. My goal here though is to improve the level of support outside of
just Fedora and its derivatives.

Re: [PATCH] selinux-testsuite: update to work on Debian

[William Roberts]

>
> On Thu, May 7, 2020 at 11:02 AM William Roberts
> <bill.c.roberts@gmail.com> wrote:
> >
> > >
> > > On Thu, May 7, 2020 at 10:49 AM Russell Coker <russell@coker.com.au> wrote:
> > > >
> > > > On Thursday, 7 May 2020 6:35:11 PM AEST Laurent Bigonville wrote:
> > > > > If people are using preseed installations (kickstart equivalent), I
> > > > > think that enabling SELinux in the installer shouldn't be too difficult
> > > > > (installing the needed packages, modifying the files and relabeling with
> > > > > fixfiles). It's obviously not user friendly, but the question is what's
> > > > > the target here.
> > > >
> > > > If we want to do that properly then I guess we want SE Linux enabled in the
> > > > kernel that the installer uses and then have the policy installed early in the
> > > > installation so the files can have the correct labels from the start instead of
> > > > having a relabel process afterwards.
> > >
> > > That would be good but might be overreach for Debian since SELinux is
> > > not the default there.  It isn't strictly necessary; ever since we
> > > went to using extended attributes for file labels, you can set them on
> > > a non-SELinux-enabled kernel, so the installer can always set them
> > > even if its kernel doesn't enable SELinux.  Optimally they would be
> > > set by the package manager based on file_contexts; that is what rpm
> > > does in Fedora/RHEL.  Or you can always run setfiles after package
> > > installation but before rebooting into the SELinux-enabled kernel.
> > > You don't need to defer labeling until you have SELinux enabled.
> >
> > On Thu, May 7, 2020 at 9:54 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> >
> > I found this:
> >   - https://man.sr.ht/builds.sr.ht/compatibility.md
> >
> > It seems to have Fedora-30,31 and rawhide.
> > It seems to be free as well (for now)
> > I would be a little leary using it, seems new, its only in alpha,
> > and looks like it could disappear at any moment.
> >
> > The travis ubuntu to fedora VM might be heavy, but it would at least provide
> > us with something stable... for awhile or we look at getting some
> > better infrastructure support for running a CI job on.
>
> Fedora's own CI infrastructure seems like a better bet for the near
> term wrt testing on Fedora; Petr appears to be already exploring using
> it.

I though the Fedora CI was limiting the amount of testing and
triggering tests, no?
Or is that why he is exploring it to see if we can get around them?

> My goal here though is to improve the level of support outside of
> just Fedora and its derivatives.

Definitely a plus.

Re: [PATCH] selinux-testsuite: update to work on Debian

[Petr Lautrbach]

[-- Attachment #1: Type: text/plain, Size: 4361 bytes --]

On Thu, May 07, 2020 at 10:22:09AM -0500, William Roberts wrote:
> >
> > On Thu, May 7, 2020 at 11:02 AM William Roberts
> > <bill.c.roberts@gmail.com> wrote:
> > >
> > > >
> > > > On Thu, May 7, 2020 at 10:49 AM Russell Coker <russell@coker.com.au> wrote:
> > > > >
> > > > > On Thursday, 7 May 2020 6:35:11 PM AEST Laurent Bigonville wrote:
> > > > > > If people are using preseed installations (kickstart equivalent), I
> > > > > > think that enabling SELinux in the installer shouldn't be too difficult
> > > > > > (installing the needed packages, modifying the files and relabeling with
> > > > > > fixfiles). It's obviously not user friendly, but the question is what's
> > > > > > the target here.
> > > > >
> > > > > If we want to do that properly then I guess we want SE Linux enabled in the
> > > > > kernel that the installer uses and then have the policy installed early in the
> > > > > installation so the files can have the correct labels from the start instead of
> > > > > having a relabel process afterwards.
> > > >
> > > > That would be good but might be overreach for Debian since SELinux is
> > > > not the default there.  It isn't strictly necessary; ever since we
> > > > went to using extended attributes for file labels, you can set them on
> > > > a non-SELinux-enabled kernel, so the installer can always set them
> > > > even if its kernel doesn't enable SELinux.  Optimally they would be
> > > > set by the package manager based on file_contexts; that is what rpm
> > > > does in Fedora/RHEL.  Or you can always run setfiles after package
> > > > installation but before rebooting into the SELinux-enabled kernel.
> > > > You don't need to defer labeling until you have SELinux enabled.
> > >
> > > On Thu, May 7, 2020 at 9:54 AM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > >
> > > I found this:
> > >   - https://man.sr.ht/builds.sr.ht/compatibility.md
> > >
> > > It seems to have Fedora-30,31 and rawhide.
> > > It seems to be free as well (for now)
> > > I would be a little leary using it, seems new, its only in alpha,
> > > and looks like it could disappear at any moment.
> > >
> > > The travis ubuntu to fedora VM might be heavy, but it would at least provide
> > > us with something stable... for awhile or we look at getting some
> > > better infrastructure support for running a CI job on.
> >
> > Fedora's own CI infrastructure seems like a better bet for the near
> > term wrt testing on Fedora; Petr appears to be already exploring using
> > it.
> 
> I though the Fedora CI was limiting the amount of testing and
> triggering tests, no?
> Or is that why he is exploring it to see if we can get around them?

The main purpose of Fedora CI is to test Fedora packages either when they're
built or when there's a pull request in pagure frontend [1]. It's configured via
tests/tests.yml [2] file.

In Fedora we use a set of integration tests originally used in Red Hat [3]

I've created "Run upstream tests on upstream sources" pull request [4] which
disables RH tests and add "upstream" test. This tests clones github repository,
build and install sources and runs `make test` from subdirectories. It's kind of
hack but seems to work [5]. I'd like to enable also Red Hat based tests for this
"upstream" test to get more and better results.

AFAIK the amount of testing is limited only in sense that you can have one run
for one pull request at the time and in order to create a pull request you
need to have a Fedora account, but you don't have to be a packager  -
https://docs.fedoraproject.org/en-US/ci/pull-requests/#_you_are_not_a_packager 


[1] https://src.fedoraproject.org/rpms
[2] https://src.fedoraproject.org/rpms/policycoreutils/blob/master/f/tests/tests.yml
[3] https://src.fedoraproject.org/tests/selinux/tree/master
[4] https://src.fedoraproject.org/rpms/policycoreutils/pull-request/15
[5] https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-pr-pipeline/detail/fedora-rawhide-pr-pipeline/3462/artifacts


> > My goal here though is to improve the level of support outside of
> > just Fedora and its derivatives.
> 
> Definitely a plus.
> 

-- 
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Fwd: [PATCH] selinux-testsuite: update to work on Debian

[Dac Override]

Forgot to hit "reply all"

I think one reboot should be enough but i don't see how you would do
it without rebooting at all.
By adding selinux=1 on the kernel boot line you effectively disable
apparmor (the apparmor service unit has a condition that disables when
selinux=1 i believe)
You dont need that selinux-activate script either. The pam config
should be set up out of the box.
all that remains it the kernel boot options and relabel AFAIK. The
boot options can be added without booting by editing /etc/default/grub
and running update-grub, but relabeling requires a reboot.

Enabling SELinux is actually amazingly simple considering the circumstances.

On Wed, May 6, 2020 at 5:52 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Wed, May 6, 2020 at 10:57 AM William Roberts
> <bill.c.roberts@gmail.com> wrote:
> >
> > On Wed, May 6, 2020 at 8:45 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > >
> > > On Tue, May 5, 2020 at 8:54 PM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > >
> > > > Update the testsuite policy and code so that it builds and
> > > > runs on Debian unstable and stable successfully (if one has
> > > > already enabled SELinux on Debian).  Provide the necessary
> > > > dependencies and instructions in the README.
> > >
> > > A few notes for anyone trying to run this on Debian:
> > >
> > > 1) There is an open bug in Debian around gdm login shells running in
> > > the wrong context (initrc_t instead of unconfined_t),
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874191, due to the
> > > /sys/fs/selinux/user ERANGE problem breaking pam_selinux for the
> > > systemd --user instance and the lack of either a policy workaround (as
> > > previously done in Fedora to limit outbound transitions from init_t to
> > > only valid cases) or the recent libselinux fix (to stop using
> > > /sys/fs/selinux/user altogether).  To permit testing without requiring
> > > my own custom policy or libselinux, I simply ran the tests from a ssh
> > > login rather than a graphical login.  Non-graphical console login
> > > probably would have worked too but I didn't try. But I have escalated
> > > the bug with the Debian SELinux maintainers in hopes of getting that
> > > fixed.
> > >
> > > 2) In Debian unstable, I also had to setsebool -P ssh_sysadm_login=1
> > > to allow ssh login as unconfined.  I let the Debian SELinux
> > > maintainers know but it isn't clear they will change the default.
> > >
> > > 3) Debian policy package ships with /etc/selinux/config set to
> > > permissive since the policy often doesn't work cleanly out of the box,
> > > so I had to manually setenforce 1 before running the testsuite.  This
> > > btw killed any gdm login sessions as well due to missing execmem and
> > > other permissions so that's another reason to not do it from a gdm
> > > login under their current policy.
> > >
> > > 4) The Debian stable kernel didn't enable CONFIG_NETLABEL so all of
> > > the netlabel-dependent inet_socket tests failed on stable.  Debian
> > > unstable kernel had CONFIG_NETLABEL enabled and they all passed there.
> > > I didn't consider it worthwhile to build my own Debian stable kernel
> > > for testing it; I just wanted to ensure that the policy worked, which
> > > I consider the Debian unstable test to prove.
> > >
> > > Interestingly, on Debian unstable, we end up running more tests than
> > > on Fedora rawhide currently: 64 test scripts with 869 individual tests
> > > versus 62 test scripts with 824 individual tests.  This is because
> > > Debian unstable's policy (which is based on a recent snapshot of
> > > refpolicy) has class and permission definitions for everything in its
> > > kernel except the lockdown class, versus Fedora which lacks the watch*
> > > permissions as well as the perf_event and lockdown classes.
> >
> > This is fantastic, I haven't looked at it fully yet. But I'm assuming this would
> > be the initial bulk work to get the make check on travis better. So in theory
> > we can just replicate this on Travis. Is my understanding correct here?
> > Ideally, we can get to a point where if CI is passing, its already an RC
> > candidate.
>
> That would be great but I don't think it is quite that easy
> unfortunately. I'm not a travis-ci expert by any means, but I don't
> think it provides us with a way to replicate the current steps
> required to enable SELinux in Debian or Ubuntu.  Debian's current
> approach to enabling SELinux involves installing some additional
> packages, running a selinux-activate script to modify the kernel
> command line in the grub configuration to enable SELinux in the kernel
> and to update some other configurations (e.g. adding pam_selinux to
> pam configs), rebooting to come up with SELinux enabled in the kernel
> and to label all filesystems, and rebooting a second time to come up
> with everything including init in the right SELinux domain.  In
> contrast I think travis-ci just provides you with a stock Ubuntu LTS
> image and allows you to install additional packages and run commands
> on that running instance, but not to specify custom kernel parameters
> initially or to reboot the system before proceeding with further
> commands (if anyone knows differently, speak up). We'd have to get to
> the point where enabling SELinux in Debian is possible without
> requiring a reboot at all.  And then we'd have to wait for that
> support to find its way into one of the Ubuntu images supported by
> travis-ci.  Might be easier to just get travis-ci to support Fedora or
> CentOS images in the first place. Regardless, allowing the testsuite
> to be run by users of other distributions is worthwhile IMHO.

Re: [PATCH] selinux-testsuite: update to work on Debian

[Stephen Smalley]

On Wed, May 6, 2020 at 4:03 PM Dac Override <dac.override@gmail.com> wrote:
> I think one reboot should be enough but i don't see how you would do
> it without rebooting at all.
> By adding selinux=1 on the kernel boot line you effectively disable
> apparmor (the apparmor service unit has a condition that disables when
> selinux=1 i believe)
> You dont need that selinux-activate script either. The pam config
> should be set up out of the box.
> all that remains it the kernel boot options and relabel AFAIK. The
> boot options can be added without booting by editing /etc/default/grub
> and running update-grub, but relabeling requires a reboot.
>
> Enabling SELinux is actually amazingly simple considering the circumstances.

With installer support for SELinux, it should be possible to specify
SELinux enablement as part of the original install and avoid the need
for a separate step to modify any configurations, relabeling, or
rebooting.  Just like Fedora.  That said, I don't know if such an
installation option would be accessible via travis-ci configuration
and thus still might not be possible to enable SELinux on a travis-ci
instance unless using your own infrastructure.

Re: [PATCH] selinux-testsuite: update to work on Debian

[Ondrej Mosnacek]

On Wed, May 6, 2020 at 2:54 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> Update the testsuite policy and code so that it builds and
> runs on Debian unstable and stable successfully (if one has
> already enabled SELinux on Debian).  Provide the necessary
> dependencies and instructions in the README.
>
> The labeled networking tests relies on specific mlsconstrain

s/relies/rely/

> statements that exist in Fedora policy but not in Debian so
> add them to the test policy as a CIL module; on Fedora this is
> redundant but harmless.  The SCTP tests also assumed that
> netlabel_peer_t was already marked mcs_constrained() in the
> base policy which doesn't appear to be true in Debian, so mark
> it so in the test policy.

[...]

> diff --git a/README.md b/README.md
> index b36494e..0d3f060 100644
> --- a/README.md
> +++ b/README.md
> @@ -36,6 +36,8 @@ one primary security module may be active at a time.
>
>  ### Userland and Base Policy
>
> +#### Fedora or RHEL
> +
>  On a Fedora/RHEL based system the testsuite has the following userspace
>  dependencies beyond a minimal install (other Linux distributions should have
>  similar dependencies):
> @@ -77,8 +79,66 @@ following command:
>                 xfsprogs-devel \
>                 libuuid-devel
>
> +#### Debian
> +
> +On Debian, you must first take steps to install and activate SELinux since
> +it is not enabled in the default install.  Be sure to backup your system first
> +if you care about any local data.
> +
> +       # apt-get install selinux-basics selinux-policy-default auditd
> +       # selinux-activate
> +       # reboot
> +
> +After activating, make sure that your login shell is running in the correct context:
> +
> +       # id -Z
> +
> +If this shows something other than "unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023",
> +you will need to first fix labeling or policy problems in your base system before proceeding.
> +Be sure that your shell context is correct and you can switch to enforcing mode without
> +breaking your system before proceeding.

Maybe it's because I'm not a native English speaker, but I parse "Be
sure that" more as "Rest assured that", at least until I reach the end
of the sentence. May I suggest using "Make sure that" instead?

> +
> +On Debian, you can install the userspace dependencies with the following
> +command:
> +
> +       # apt-get install perl \
> +               gcc \
> +               selinux-policy-dev \
> +               libselinux1-dev \
> +               net-tools \
> +               iptables \
> +               libsctp-dev \
> +               attr \
> +               libbpf-dev \
> +               libkeyutils-dev \
> +               linux-headers-$(uname -r) \
> +               quota \
> +               xfsprogs \
> +               xfslibs-dev \
> +               uuid-dev
> +
> +On Debian, you need to build and install netlabel_tools manually since it is not
> +yet packaged for Debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959806):
> +
> +    # git clone https://github.com/netlabel/netlabel_tools
> +    # cd netlabel_tools
> +    # sudo apt-get install autotools-dev autoconf automake libtool pkg-config libnl-3-dev libnl-genl-3-dev
> +    # ./autogen.sh
> +    # ./configure --prefix=/usr
> +    # make
> +    # sudo make install
> +
> +Debian further requires reconfiguring the default /bin/sh to be bash
> +to support bashisms employed in the testsuite Makefiles and scripts:
> +
> +    # dpkg-reconfigure dash
> +
> +Select No when asked if you want to use dash as the default system shell.

Maybe add quotes around "No"?

> +
> +#### Other Distributions
> +
>  The testsuite requires a pre-existing base policy configuration of SELinux,
> -using either the old example policy or the reference policy as the baseline.
> +using the reference policy as the baseline.
>  It also requires the core SELinux userland packages (`libsepol`, `checkpolicy`,
>  `libselinux`, `policycoreutils`, and if using modular policy, `libsemanage`)
>  to be installed.  The test scripts also rely upon the SELinux extensions being
> diff --git a/policy/Makefile b/policy/Makefile
> index dfe601b..f86aac4 100644
> --- a/policy/Makefile
> +++ b/policy/Makefile
> @@ -40,6 +40,8 @@ CIL_TARGETS = test_add_levels.cil test_glblub.cil
>  endif
>  endif # GLBLUB
>
> +CIL_TARGETS += test_mlsconstrain.cil test_overlay_defaultrange.cil

This causes a problem on RHEL-6, since it doesn't understand CIL
modules. We'll probably need to detect if semodule supports CIL before
trying to add the modules.

> +
>  ifeq ($(shell [ $(POL_VERS) -ge 24 ] && echo true),true)
>  TARGETS += test_bounds.te test_nnp_nosuid.te
>  endif
> @@ -161,12 +163,16 @@ build: $(TARGETS)
>
>  load: expand_check all
>         # General policy load
> -       @-/usr/sbin/setsebool allow_domain_fd_use=0
> +       @if [ -e /sys/fs/selinux/booleans/domain_fd_use ]; then \
> +               /usr/sbin/setsebool domain_fd_use=0; \

On RHEL-6, the boolean is actually called allow_domain_fd_use, so it
doesn't set the boolean, leading to failures in fdreceive and inherit
test. Could we use getsebool and allow_domain_fd_use instead? It
should be able to resolve the alias on all systems where the boolean
exists.

> +       fi
>         $(SEMODULE) -i test_policy/test_policy.pp $(CIL_TARGETS)
>
>  unload:
>         # General policy unload
> -       @-/usr/sbin/setsebool allow_domain_fd_use=1
> +       @if [ -e /sys/fs/selinux/booleans/domain_fd_use ]; then \
> +               /usr/sbin/setsebool domain_fd_use=1; \

Same as above.

> +       fi
>         $(SEMODULE) -r test_policy $(subst .cil,,$(CIL_TARGETS))
>
>  clean:
> diff --git a/policy/test_capable_net.te b/policy/test_capable_net.te
> index 80559f6..2255a14 100644
> --- a/policy/test_capable_net.te
> +++ b/policy/test_capable_net.te
> @@ -28,8 +28,6 @@ corenet_raw_sendrecv_generic_if(capabledomain)
>  corenet_tcp_sendrecv_all_nodes(capabledomain)
>  corenet_udp_sendrecv_all_nodes(capabledomain)
>  corenet_raw_sendrecv_all_nodes(capabledomain)
> -corenet_tcp_sendrecv_all_ports(capabledomain)
> -corenet_udp_sendrecv_all_ports(capabledomain)
>  corenet_all_recvfrom_unlabeled(test_ncap_t)
>  corenet_all_recvfrom_unlabeled(test_resncap_t)
>  corenet_tcp_bind_all_nodes(capabledomain)
> diff --git a/policy/test_execute_no_trans.te b/policy/test_execute_no_trans.te
> index 79ba868..f699f56 100644
> --- a/policy/test_execute_no_trans.te
> +++ b/policy/test_execute_no_trans.te
> @@ -24,4 +24,4 @@ userdom_sysadm_entry_spec_domtrans_to(test_execute_notrans_t)
>
>  #Allow test_execute_notrans permissions to the allowed type
>  can_exec(test_execute_notrans_t,test_execute_notrans_allowed_t)
> -allow test_execute_notrans_t test_execute_notrans_denied_t:file mmap_file_perms;
> +allow test_execute_notrans_t test_execute_notrans_denied_t:file mmap_exec_file_perms;

This causes the testsuite to fail on RHEL-7, since there
mmap_exec_file_perms includes execute_no_trans for some reason. And on
RHEL-6 mmap_exec_file_perms is not defined at all. Can we solve this
bz defining mmap_exec_file_perms as mmap_file_perms in test_policy.if
if mmap_exec_file_perms is not defined?

> diff --git a/policy/test_filesystem.te b/policy/test_filesystem.te
> index 7d73cbf..4e27134 100644
> --- a/policy/test_filesystem.te
> +++ b/policy/test_filesystem.te
> @@ -350,6 +350,7 @@ allow test_filesystem_fscontext_t test_filesystem_filecon_t:file { getattr open
>  allow test_filesystem_fscontext_t test_filesystem_fscontext_fs_t:dir { add_name search write };
>  allow test_filesystem_fscontext_t test_filesystem_fscontext_fs_t:file { create getattr open relabelfrom write };
>  allow test_filesystem_fscontext_t test_filesystem_fscontext_fs_t:filesystem { mount relabelto unmount };
> +domain_obj_id_change_exemption(test_filesystem_fscontext_t)
>  fs_relabelfrom_all_fs(test_filesystem_fscontext_t)
>  files_search_all(test_filesystem_fscontext_t)
>  allow test_filesystem_filecon_t test_filesystem_fscontext_fs_t:filesystem { associate };

[...]

This is what I discovered so far just by trying the patch on various
RHELs and reading the text parts of the patch. I plan to have a closer
look later.

-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.

Re: [PATCH] selinux-testsuite: update to work on Debian

[Stephen Smalley]

On Wed, May 6, 2020 at 3:37 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> On Wed, May 6, 2020 at 2:54 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> > diff --git a/policy/Makefile b/policy/Makefile
> > index dfe601b..f86aac4 100644
> > --- a/policy/Makefile
> > +++ b/policy/Makefile
> > @@ -40,6 +40,8 @@ CIL_TARGETS = test_add_levels.cil test_glblub.cil
> >  endif
> >  endif # GLBLUB
> >
> > +CIL_TARGETS += test_mlsconstrain.cil test_overlay_defaultrange.cil
>
> This causes a problem on RHEL-6, since it doesn't understand CIL
> modules. We'll probably need to detect if semodule supports CIL before
> trying to add the modules.

I thought we had stopped worrying about RHEL compatibility in the
upstream testsuite going forward and deferring all of those tweaks to
downstream?  I'm not fundamentally opposed but that was the impression
I had received earlier.  If we are still carrying RHEL support, then
how old of RHEL do we still care about?  RHEL-6 is six months away
from regular EOL?

> > diff --git a/policy/test_execute_no_trans.te b/policy/test_execute_no_trans.te
> > index 79ba868..f699f56 100644
> > --- a/policy/test_execute_no_trans.te
> > +++ b/policy/test_execute_no_trans.te
> > @@ -24,4 +24,4 @@ userdom_sysadm_entry_spec_domtrans_to(test_execute_notrans_t)
> >
> >  #Allow test_execute_notrans permissions to the allowed type
> >  can_exec(test_execute_notrans_t,test_execute_notrans_allowed_t)
> > -allow test_execute_notrans_t test_execute_notrans_denied_t:file mmap_file_perms;
> > +allow test_execute_notrans_t test_execute_notrans_denied_t:file mmap_exec_file_perms;
>
> This causes the testsuite to fail on RHEL-7, since there
> mmap_exec_file_perms includes execute_no_trans for some reason. And on
> RHEL-6 mmap_exec_file_perms is not defined at all. Can we solve this
> bz defining mmap_exec_file_perms as mmap_file_perms in test_policy.if
> if mmap_exec_file_perms is not defined?

Yes, if we are still providing RHEL-7 compatibility for the testsuite,
that's easy enough.

Re: [PATCH] selinux-testsuite: update to work on Debian

[Stephen Smalley]

On Wed, May 6, 2020 at 3:57 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Wed, May 6, 2020 at 3:37 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> >
> > On Wed, May 6, 2020 at 2:54 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > > diff --git a/policy/Makefile b/policy/Makefile
> > > index dfe601b..f86aac4 100644
> > > --- a/policy/Makefile
> > > +++ b/policy/Makefile
> > > @@ -40,6 +40,8 @@ CIL_TARGETS = test_add_levels.cil test_glblub.cil
> > >  endif
> > >  endif # GLBLUB
> > >
> > > +CIL_TARGETS += test_mlsconstrain.cil test_overlay_defaultrange.cil
> >
> > This causes a problem on RHEL-6, since it doesn't understand CIL
> > modules. We'll probably need to detect if semodule supports CIL before
> > trying to add the modules.
>
> I thought we had stopped worrying about RHEL compatibility in the
> upstream testsuite going forward and deferring all of those tweaks to
> downstream?  I'm not fundamentally opposed but that was the impression
> I had received earlier.  If we are still carrying RHEL support, then
> how old of RHEL do we still care about?  RHEL-6 is six months away
> from regular EOL?

Also not sure what we would test here to determine whether CIL is supported.
It isn't directly linked to a particular kernel or module binary
policy version, and the version of libsepol that first introduced it
in RHEL-7 probably differs from upstream (assuming it was back-ported
there).

>
> > > diff --git a/policy/test_execute_no_trans.te b/policy/test_execute_no_trans.te
> > > index 79ba868..f699f56 100644
> > > --- a/policy/test_execute_no_trans.te
> > > +++ b/policy/test_execute_no_trans.te
> > > @@ -24,4 +24,4 @@ userdom_sysadm_entry_spec_domtrans_to(test_execute_notrans_t)
> > >
> > >  #Allow test_execute_notrans permissions to the allowed type
> > >  can_exec(test_execute_notrans_t,test_execute_notrans_allowed_t)
> > > -allow test_execute_notrans_t test_execute_notrans_denied_t:file mmap_file_perms;
> > > +allow test_execute_notrans_t test_execute_notrans_denied_t:file mmap_exec_file_perms;
> >
> > This causes the testsuite to fail on RHEL-7, since there
> > mmap_exec_file_perms includes execute_no_trans for some reason. And on
> > RHEL-6 mmap_exec_file_perms is not defined at all. Can we solve this
> > bz defining mmap_exec_file_perms as mmap_file_perms in test_policy.if
> > if mmap_exec_file_perms is not defined?
>
> Yes, if we are still providing RHEL-7 compatibility for the testsuite,
> that's easy enough.

Actually on second thought that seems problematic since RHEL-7 defines
it but defines it differently.  So essentially I'd just need to
undefine it and redefine it always, or just inline the definition
itself here.

Re: [PATCH] selinux-testsuite: update to work on Debian

[Ondrej Mosnacek]

On Wed, May 6, 2020 at 10:27 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Wed, May 6, 2020 at 3:57 PM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Wed, May 6, 2020 at 3:37 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > >
> > > On Wed, May 6, 2020 at 2:54 AM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > > diff --git a/policy/Makefile b/policy/Makefile
> > > > index dfe601b..f86aac4 100644
> > > > --- a/policy/Makefile
> > > > +++ b/policy/Makefile
> > > > @@ -40,6 +40,8 @@ CIL_TARGETS = test_add_levels.cil test_glblub.cil
> > > >  endif
> > > >  endif # GLBLUB
> > > >
> > > > +CIL_TARGETS += test_mlsconstrain.cil test_overlay_defaultrange.cil
> > >
> > > This causes a problem on RHEL-6, since it doesn't understand CIL
> > > modules. We'll probably need to detect if semodule supports CIL before
> > > trying to add the modules.
> >
> > I thought we had stopped worrying about RHEL compatibility in the
> > upstream testsuite going forward and deferring all of those tweaks to
> > downstream?  I'm not fundamentally opposed but that was the impression
> > I had received earlier.  If we are still carrying RHEL support, then
> > how old of RHEL do we still care about?  RHEL-6 is six months away
> > from regular EOL?

I'd still like to keep compatibility with at least RHEL-6+ (with older
versions approaching EOL being less important than newer ones) at
least where it can be achieved easily (without too intrusive changes).

>
> Also not sure what we would test here to determine whether CIL is supported.
> It isn't directly linked to a particular kernel or module binary
> policy version, and the version of libsepol that first introduced it
> in RHEL-7 probably differs from upstream (assuming it was back-ported
> there).

Hm... yes, I sent the email late in the evening and hadn't given it
proper thought. I agree this would be too much trouble for little
gain.

-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.