Linux 5.14 Released

Linux v5.14 was released on Sunday, August 29th; the SELinux and audit highlights are below:

SELinux

  • Remove some limitations in the inode permission check code so that the kernel can update the SELinux Access Vector Cache (AVC) even in cases where it is not allowed to block the caller. This should result in less slow-path permission lookups and better use of the SELinux AVC.

  • Fixed a problem where an invalid initial SID did not correctly return an error to userspace when a policy was loaded into the kernel.

  • Memory allocation failures when updating the SELinux AVC no longer generate kernel warnings when the kernel is configured to generate failed allocation warnings. These failures are not fatal in any way, the AVC is a cache after all, but on some memory constrained systems the warnings can quickly fill the logs in certain configurations.

  • Minor improvements to the InfiniBand and policy DB string handling code which should result in better code quality and performance.

  • Minor code cleanups involving unused function parameters, kernel documentation fixes, and removal of redundant code.

Audit

  • Rename the enumerated type values used to indicate the audit state as the existing values collided with other names in the kernel.

  • Various minor style fixes to the audit code to better fit with existing kernel coding conventions.

Linux 5.13 Released

Linux v5.13 was released on Sunday, June 27th; the SELinux and audit highlights are below:

SELinux

  • Linux v5.12 added basic SELinux policy measurements to IMA and with this kernel release support for the SELinux state variables and policy capabilities have been added. Lakshmi Ramasubramanian goes into detail in the commit description:

    SELinux stores the configuration state and the policy capabilities in kernel memory. Changes to this data at runtime would have an impact on the security guarantees provided by SELinux. Measuring this data through IMA subsystem provides a tamper-resistant way for an attestation service to remotely validate it at runtime.

    Measure the configuration state and policy capabilities by calling the IMA hook ima_measure_critical_data().

    To enable SELinux data measurement, the following steps are required:

    1. Add “ima_policy=critical_data” to the kernel command line arguments to enable measuring SELinux data at boot time. For example:
      BOOT_IMAGE=/boot/vmlinuz-5.11.0-rc3+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data
      
    2. Add the following rule to /etc/ima/ima-policy
      measure func=CRITICAL_DATA label=selinux
      

    Sample measurement of SELinux state and policy capabilities:

    10 2122...65d8 ima-buf sha256:13c2...1292 selinux-state 696e...303b
    

    Execute the following command to extract the measured data from the IMA’s runtime measurements list:

    grep "selinux-state" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6 | xxd -r -p
    

    The output should be a list of key-value pairs. For example:

    initialized=1;enforcing=0;checkreqprot=1;network_peer_controls=1;open_perms=1;extended_socket_class=1;always_check_network=0;cgroup_seclabel=1;nnp_nosuid_transition=1;genfs_seclabel_symlinks=0;
    

    To verify the measurement is consistent with the current SELinux state reported on the system, compare the integer values in the following files with those set in the IMA measurement (using the following commands):

    cat /sys/fs/selinux/enforce
    cat /sys/fs/selinux/checkreqprot
    cat /sys/fs/selinux/policy_capabilities/[capability_file]
    

    Note that the actual verification would be against an expected state and done on a separate system (likely an attestation server) requiring

    initialized=1;enforcing=1;checkreqprot=0;
    

    for a secure state and then whatever policy capabilities are actually set in the expected policy (which can be extracted from the policy itself via seinfo, for example).

  • Fix a problem with SELinux/NFS where the SELinux security context was not properly considered when NFS made a decision to share a filesystem superblock. Olga Kornievskaia explains how this problem could manifest itself in the commit description:

    Previously, with selinux enabled, NFS wasn’t able to do the following 2 mounts:

    mount -o vers=4.2,sec=sys,context=system_u:object_r:root_t:s0 <serverip>:/ /mnt
    mount -o vers=4.2,sec=sys,context=system_u:object_r:swapfile_t:s0 <serverip>:/scratch /scratch
    

    2nd mount would fail with “mount.nfs: an incorrect mount option was specified” and /var/log/messages would have: “SElinux: mount invalid. Same superblock, different security settings for..”

  • Fix a problem where the LSM hooks did not properly differentiate between the subjective and objective LSM credentials. The existing “security_task_getsecid()” LSM hook provides the task’s objective LSM credentials despite many callers expecting the subjective LSM credentials. The solution is to split the existing LSM hook into two new hooks, one for each credential type, and adjust the callers as appropriate. The new LSM hooks are named “security_task_getsecid_subj()” and “security_task_getsecid_obj()”; the “security_task_getsecid()” hook has been removed.

  • Fix a problem preventing overlayfs context mounts in an unprivileged namespace.

  • Fix a problem where we were not properly terminating the kernel internal permission list for two SELinux object classes, “bpf” and “perf_event”.

  • A number of spelling corrections in the kernel source comments.

Audit

  • Remove some unused code related to the audit syscall entry filters which were removed in Linux v4.17, over three years ago.

  • Fix some compiler warnings when audit is disabled at kernel build time.

  • Minor kernel documentation updates regarding the audit related files in procfs.

Linux 5.12 Released

Linux v5.12 was released on Sunday, April 25th. While it was another relatively quiet release for audit, SELinux had a number of changes; the highlights are below:

SELinux

  • Support was added for controlling anonymous inodes with SELinux. In order to make use of these new controls the various kernel subsystems need to opt-in to SELinux policy enforcement by using a different anonymous inode kernel API; the first user of this new API is userfaultfd. The authors of the work, Daniel Colascione and Lokesh Gidra, provide a simple explantion of how to use the new userfaultfd controls under SELinux:

    A SELinux policy author detects and controls these anonymous inodes by adding a name-based type_transition rule that assigns a new security type to anonymous-inode files created in some domain. The name used for the name-based transition is the name associated with the anonymous inode for file listings — e.g., “[userfaultfd]” or “[perf_event]”.

    Example:

    type uffd_t;
    type_transition sysadm_t sysadm_t : anon_inode uffd_t "[userfaultfd]";
    allow sysadm_t uffd_t:anon_inode { create };
    
  • Filesystems can now be configured to use both xattr and genfs file labeling support in the SELinux policy and the kernel will fallback to genfs if the filesystem does not support xattr labeling. While this may not be very useful for traditional filesystem such as ext4, it is helpful for filesystems such as virtiofs where the filesystem capabilities can vary depending on the backing filesystem.

  • IMA can now measure the loaded SELinux policy. Lakshmi Ramasubramanian explains why this is important and how to make use of this new capability in the commit description:

    SELinux stores the active policy in memory, so the changes to this data at runtime would have an impact on the security guarantees provided by SELinux. Measuring in-memory SELinux policy through IMA subsystem provides a secure way for the attestation service to remotely validate the policy contents at runtime.

    Measure the hash of the loaded policy by calling the IMA hook ima_measure_critical_data(). Since the size of the loaded policy can be large (several MB), measure the hash of the policy instead of the entire policy to avoid bloating the IMA log entry.

    To enable SELinux data measurement, the following steps are required:

    1, Add “ima_policy=critical_data” to the kernel command line arguments to enable measuring SELinux data at boot time. For example,

    BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data
    

    2, Add the following rule to /etc/ima/ima-policy measure func=CRITICAL_DATA label=selinux

    Sample measurement of the hash of SELinux policy:

    To verify the measured data with the current SELinux policy run the following commands and verify the output hash values match.

    sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
    
    grep "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6
    

    Note that the actual verification of SELinux policy would require loading the expected policy into an identical kernel on a pristine/known-safe system and run the sha256sum /sys/kernel/selinux/policy there to get the expected hash.

  • SELinux now properly classifies MPTCP sockets the same as TCP sockets.

  • A problem with overlayfs was fixed that impacted systems where SELinux was enabled but a policy had not yet been loaded.

  • A potential use-after-free problem during SELinux policy reloading was fixed. While normally such bugs can be serious, loading a new SELinux policy is already a privileged operation so the risk should be low.

  • Potential problems relating to SELinux label conversion during policy reloading have been fixed.

  • Potential problems involving SELinux policy booleans incorrectly enabling or disabling SELinux policy have been fixed.

  • Some incorrect and inconsistent kernel messages generated when loading a SELinux policy were fixed.

  • A small number of unused variables were removed from the SELinux code, some private variable were correctly marked as static, and number of other variables were marked as “__ro_after_init” or “__read_mostly” as appropriate.

Audit

  • A few trivial changes to cleanup the code and correct some typos; there should be no noticeable changes.