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

[Dac Override <dac.override@gmail.com>]

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.