On Wed, May 6, 2020 at 10:50 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > On Wed, May 6, 2020 at 10:57 AM William Roberts > <bill.c.roberts@xxxxxxxxx> wrote: > > > > 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. > > 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.
