| Message ID | 20200506005339.13641-1-stephen.smalley.work@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Ondrej Mosnáček |
| Headers | show |
| Series | selinux-testsuite: update to work on Debian | expand |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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 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.
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.
> > 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.
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 :)
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. >
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.
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
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.
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. >
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
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. >
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";
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