Le 7/05/20 à 14:51, Stephen Smalley a écrit :
On Thu, May 7, 2020 at 4:46 AM Laurent Bigonville <bigon@xxxxxxxxxx> 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
