Linux v4.16 was released on Sunday, April 1st; this is a quick summary of the SELinux and audit changes. Fair warning, this was a very small release from a SELinux and audit perspective, but v4.17 should be back to normal and perhaps even a bit larger than normal if everything works out.
Fixed two small problems identified by syzbot/syzkaller that could only be triggered during early boot (SELinux enabled, but no policy loaded). It is extremely unlikely that these bugs would ever be seen by normal users as there is little point of running a system with SELinux enabled and not loading a security policy.
Updated the SELinux kernel copyright notices to reference the FSF's website address and not their postal address.
There were no audit fixes or improvements in Linux v4.16.
Linux v4.15 was released on Sunday, January 28th; this is a quick summary of the SELinux and audit changes.
A new SELinux object class was added, "bpf", to control access to the extended Berkeley Packet Filter (eBPF) virtual machine in the Linux Kernel, which can be accessed via the bpf(2) system call. The new object class is defined with the following permissions: The "map_create" permission controls the ability to create new eBPF maps, where the "map_read" and "map_write" permissions control read and write access to eBPF maps. The "prog_load" permission controls the ability to load an eBPF program into the kernel and the "prog_run" permission controls the ability execute a previously loaded eBPF program. Like most system resources, eBPF maps and programs inherit their labels from the originating SELinux domain.
The file extended attribute permission code was changed to use the common capability code for any non-SELinux extended attributes. This fixed a problem with file capabilities in user namespaces.
Converted the SELinux internal hash table implementation to use kmem_cache, reducing runtime memory consumption by a small amount.
Various small code cleanups to remove build warnings and unneeded variable assignments.
Due to a large number of PATH records created by tracefs and debugfs, a new mechanism was introduced which allows the filtering of PATH records based on the filesystem type. Richard Guy Briggs provides a good explanation of this new feature in the patch's description:
From: Richard Guy Briggs
audit: filter PATH records keyed on filesystem magic
Tracefs or debugfs were causing hundreds to thousands of PATH records to be associated with the init_module and finit_module SYSCALL records on a few modules when the following rule was in place for startup: -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
Provide a method to ignore these large number of PATH records from overwhelming the logs if they are not of interest. Introduce a new filter list "AUDIT_FILTER_FS", with a new field type AUDIT_FSTYPE, which keys off the filesystem 4-octet hexadecimal magic identifier to filter specific filesystem PATH records.
An example rule would look like: -a never,filesystem -F fstype=0x74726163 -F key=ignore_tracefs -a never,filesystem -F fstype=0x64626720 -F key=ignore_debugfs
Arguably the better way to address this issue is to disable tracefs and debugfs on boot from production systems.
Fixed a bug where the kernel was not initializing the audit subsystem early enough at boot and was missing audit records generated by PID 1 (init/systemd/etc.). In addition to fixing this particular bug there were a number of small code cleanups and general improvements to the audit initialization code.
Fixed a bug where the kernel did not recognize when the audit daemon was attempting to shut down the kernel/auditd connection by sending an AUDIT_SET message with a PID 0 value.
The audit file and directory write syscall filters were updated with additional syscalls.
An old and unused function, audit_log_secctx(), was removed.
UPDATE: Added mention of the SELinux "bpf" object class that was added in Linux v4.15.
Another year, another DevConf.cz in the books. Thanks to everyone who attended, volunteered, and spoke; it was a great conference and I'm once again looking forward to next year. I should also mention that for the first time ever, DevConf will be expanding to two other locations in 2018: Boston and Bangalore, check the websites for more details.
At this year's DevConf.cz I gave a short talk on an effort we are calling "SELinux Modularity", a project where we are working on integrating SELinux into the larger Fedora Modularity effort.