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@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. > 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 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Attachment:
signature.asc
Description: PGP signature
