Linux 4.4 Released

Linus released Linux 4.4 last week, and while I’m a bit late in posting this, here are the SELinux and audit release notes for the new kernel release.

SELinux

• The CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE Kconfig value default was changed to 0. This change means that by default the kernel will now perform SELinux mmap() and mprotect() access control checks based on the protection actually applied by the kernel as opposed to the protection requested by the application.

• SELinux no longer checks the file:open permission on ftruncate() as it has already been checked when the file was opened.

• Fix a bug where conditional policy was ignored for userspace object managers.

• General cleanup and code improvements.

Audit

• Improved the communication between the kernel and the audit daemon which should result in improved resiliency.

• General cleanup and code improvements.

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