Kernel Repository Process

It has been over a year since I formally updated the SELinux and audit kernel repository processes, and based on how things have evolved it seems we are due for another update. This time the changes are rather small, and shouldn't surprise anyone who has been following upstream development.

SELinux

  1. After the merge window closes upstream, patches will be merged into the selinux/next branch up until the merge window reopens. However, it is important to note that large, complicated, or invasive patches sent late in the development cycle may be deferred until the next cycle.

  2. Any patches deemed necessary for the current Linux -rcX releases will be merged into the current selinux/stable-X.Y branch, marked with a signed tag, and a pull request sent against linux/master as soon as it is reasonable to do so.

  3. During the development cycle Fedora Rawhide test kernels will be generated using the selinux/next and most recent selinux/stable-X.Y branches on a weekly basis, if not more often. These kernels will be tested against the SELinux test suite and made available to everyone for additional testing.

  4. Once the merge window opens a decision will be made if there is a need to rebase the current selinux/next branch on top of the recent Linux release. In general rebases should be limited, but rebases will be necessary over time to keep the selinux/next branch reasonably current. If the selinux/next branch is to be rebased, it should be done very early in the merge window and additional care should be taken to ensure that it passes all of the SELinux regression tests.

  5. After any rebases have taken place, the selinux/next branch will be copied to a new branch, selinux/stable-X.Y, and the branch will be marked with a signed tag in the format selinux-pr-YYYYMMDD. A pull request will be sent against the linux/master branch using the signed tag.

Audit

  1. After the merge window closes upstream, patches will be merged into the audit/next branch up until the merge window reopens. However, it is important to note that large, complicated, or invasive patches sent late in the development cycle may be deferred until the next cycle.

  2. Any patches deemed necessary for the current Linux -rcX releases will be merged into the current audit/stable-X.Y branch, marked with a signed tag, and a pull request sent against linux/master as soon as it is reasonable to do so.

  3. During the development cycle Fedora Rawhide test kernels will be generated using the audit/next and most recent audit/stable-X.Y branches on a weekly basis, if not more often. These kernels will be tested against the audit test suite and made available to everyone for additional testing.

  4. Once the merge window opens a decision will be made if there is a need to rebase the current audit/next branch on top of the recent Linux release. In general rebases should be limited, but rebases will be necessary over time to keep the audit/next branch reasonably current. If the audit/next branch is to be rebased, it should be done very early in the merge window and additional care should be taken to ensure that it passes all of the audit regression tests.

  5. After any rebases have taken place, the audit/next branch will be copied to a new branch, audit/stable-X.Y, and the branch will be marked with a signed tag in the format audit-pr-YYYYMMDD. A pull request will be sent against the linux/master branch using the signed tag.

For reference, the previous process was defined here.

UPDATE: The SELinux kernel process has been updated now that we are basing the tree against Linus' tree and sending pull requests directly to Linus.

Kernel Repository Move

In a move that is long overdue, I'm moving the SELinux and audit repositories from infradead.org to kernel.org. The URLs for both repositories are shown below:

SELinux

Audit

Linux 4.12 Released

Linux v4.12 was released this past weekend on Sunday, July 2nd; this is a quick summary of the SELinux and audit changes.

SELinux

  • A new SELinux access control check was added for prlimit(2). This new access control is intended to allow SELinux policy developers the ability to control when one process attempts to read or modify another process' resource limits using the "process:{ setrlimit getrlimit }" permissions. SELinux does not restrict a process from manipulating its own resource limits via prlimit(2).

  • Reorder the CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH capability checks in the internal "generic_permission()" function so that CAP_DAC_OVERRIDE is checked after CAP_DAC_READ_SEARCH. This ensures that CAP_DAC_OVERRIDE is only checked for operations where it is required.

  • Constify the kernel's internal netlink message permission mapping tables to help prevent unwanted tampering.

  • Cleanup the kernel's internal network address handling in the SELinux bind(2) hook by ensuring that the address length is correct for the address family.

  • Multiple kernel internal cleanups and simplifications.

Audit

  • Log the name of the kernel module, via the KERN_MODULE record, when the module is removed from the kernel. See the GitHub feature page for more information.

  • Simplify and normalize the NETFILTER_PKT record to make it easier to parse in userspace and to enable future enhancement if needed. The new record includes the netfilter mark, via "mark", the source address, via "saddr", the destination address, via "daddr", and the upper layer protocol, via "proto".

  • Replace the audit subsystem's audit_buffer management mechanism with the standard kmem_cache mechanism. This simplifies the kernel's audit code and should provide for better runtime memory management.

  • Convert a number of atomic_t reference counters to refcount_t. This change should help guard against reference count overflows in the audit subsystem.

  • Convert the audit subsystem in the kernel to use 64-bit timestamps. This should make the audit subsystem year 2038 safe.

  • Convert the kernel's auditd PID tracking to use the pid struct and not the pid_t scalar type.

  • All audit netlink messages sent by the kernel now use a netlink port ID value of zero. This brings audit inline with the netlink specification.

  • Fix some problems with the RCU locking relating to auditd connection tracking. With any luck this should be the last of the auditd connection tracking fixes for a while.