Kernel Repository Process

Update: new process defined here

In an effort to make it a bit easier to maintain the kernel-secnext COPR repository I’m making some slight changes to how I manage the SELinux and audit kernel repositories. The downside is that there is now going to be a regular rebase as part of the release cycle, but at least it will be well defined and part of the process, unlike the current reactionary rebases.

Starting with the next merge window, I’ll be following the process below:

1. When a new kernel is released, rebase the repository’s upstream branch to the tagged kernel release (or the latest LSM upstream branch in the case of SELinux) and apply the next branch on top of the upstream branch. Send a pull request for the upstream branch to the next level maintainer.

2. Create a new branch, stable-X.XX, a copy of the upstream branch that was sent during the merge window.

3. Reset the next branch to the upstream branch that was sent during the merge window. At this point the upstream, next, and latest stable-X.XX branch should be identical.

4. Accept patches into both the stable-X.XX and next branches; as necessary, send pull requests for stable-X.XX to the next level maintainer. Continue until the next kernel is released and the process repeats.

As in the past, this process is subject to change, but I’m hopeful that this approach should work for the foreseeable future.

Experimental Rawhide Kernels

For the past few weeks I’ve been building experimental Fedora Rawhide kernels with all of the SELinux and audit kernel patches targeted for linux-next included. It has worked out reasonably well, and with the exception of getting a working Linux 4.4-rc1 build this week, it has proven to be relatively easy to manage. If you would like to help with testing and don’t mind the instability that comes with development kernels, the Fedora COPR repository link is below.

I’ve been doing at least one build each week, sometimes more, and I expect to continue with that frequency. I also perform a quick sanity check on each successful build, including running the SELinux and audit testsuites; however, there may be times when the kernel is simply broken, so exercise caution and please don’t run these kernels on anything critical.

pcmoore/kernel-secnext COPR repository

Linux 4.3 Released

The Linux Kernel 4.3 release was yesterday and with this new release comes new functionality and fixes for both SELinux and audit.

SELinux

• Finer grained access controls for ioctl() commands. Policy authors now have the ability to specify individual ioctl commands in SELinux policy, whereas before the granularity was limited to the ioctl syscall itself.

• Fixes to the kernel’s mdp tool to work with current versions of the checkpolicy policy compiler. For those of you who aren’t aware, the mdp tool, which lives in the kernel under scripts/selinux/mdp, can be used to create a bare bones dummy policy for SELinux.

• Internal improvements to object class initialization and handling.

Audit

• Allow the creation of audit rules based on executable pathnames. Previous to this patch administrators were forced to create audit rules using PIDs, which was limiting for a number of obvious reasons. This new functionality allows administrators to specify the pathname of an executable and the process will be audited when it executes. Unfortunately, the audit userspace tools do not yet have the necessary support to use this new functionality, but it should be coming in the next release.

• Fixes to internal audit reference counters.