DevConf.cz finished a few hours ago, and there were some really good SELinux talks. Miroslav Grepl summarized the SELinux work over the past year, and gave a preview of what we can expect over the next year. Milos Malik presented his work on a SELinux troubleshooting flowchart; if you’re having problems with SELinux denials and don’t know where to start I suggest giving it a try.
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.
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.
Improved the communication between the kernel and the audit daemon which should result in improved resiliency.
General cleanup and code improvements.
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:
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.
Create a new branch, stable-X.XX, a copy of the upstream branch that was sent during the merge window.
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.
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.
