On Wed, May 6, 2020 at 8:45 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > On Tue, May 5, 2020 at 8:54 PM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> 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.
