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.

Linux 5.11 Released

Linux v5.11 was released on Sunday, February 14, 2021 (happy Valentine’s Day!). It was a relatively small release from a SELinux and audit perspective, but the highlights are below:

SELinux

  • Changed the LSM network hooks to pass “flowi_common” structs instead of the parent “flowi” struct; the LSMs do not currently need the full “flowi” struct and they do not have the address family information necessary to use it safely.

  • Fix how we handle errors in “inode_doinit_with_dentry()” so that we attempt to properly label the inode on following lookups instead of continuing to treat the inode as unlabeled.

  • Update the kernel logic around the SELinux “allowx”, “auditallowx”, and “dontauditx” policy statements such that “auditx” and “dontauditx” are effective even without the “allowx” statement.

  • A number of smaller changes to mark some LSM hook parameters as constant and fix a “switch” statement fall-through warning in Clang.

Audit

  • Linux v5.7 changed how audit records were generated such that mandatory audit records could trigger the creation of various accompanying records (e.g. SYSCALL records). Unfortunately, a number of problems were found and this change had to be reverted in Linux v5.8. With this kernel release we have fixed all of the outstanding problems and restored this behavior. This change should help provide additional context around various audit events, making it easier for administrators to understand what was actually happening on the system.