11 May 2019 tags: audit selinux Linux v5.1 was released on Sunday, May 5th, 2019. Below are the SELinux and audit highlights for the release:
SELinux
- If SELinux is asked to perform an access control check on a file with an invalid SELinux label, the invalid label is now recorded in the SELinux AVC audit record using the “trawcon” field. An example is shown below:
type=AVC msg=audit(1547801083.248:11): avc: denied { open } for pid=1149
comm="cat" path="/tmp/testfile" dev="tmpfs" ino=6608
scontext=system_u:system_r:sshd_t:s0
tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=file
permissive=1 trawcon=system_u:object_r:banana_t:s0
-
Support was added for proper labeling of kernfs based filesystems. This is of particular interest to those running containers as the cgroup2 filesystem is based on kernfs.
-
A number of changes throughout the SELinux code to support the newly added LSM stacking code. While this is a rather significant change to the LSM layer, it should have little effect on existing systems as long as the administrator does not enable the LSM stacking functionality.
-
The constant sized flex_array structures were converted to use vmalloc allocated memory. Since these were constant sized arrays the flex_array mechanism only added unnecessary complexity.
-
The SELinux VFS code was updated to use the new internal kernel mounting API. This should have no visible impact to users, administrators, or policy developers.
-
Fix a problem with labeled NFS where mounting a NFS filesystem twice would result in disabling support for the SELinux labels.
-
Fix a problem where SELinux file access control denials might not have been logged when in permissive mode.
- A few smaller bug fixes not worth mentioning here, but which are still visible in the git log for those who are interested.
Audit
-
The CONFIG_CHANGE records are now associated with other relevant records into a single audit event. Prior to this change the CONFIG_CHANGE records were always standalone records in their own audit event.
-
An “op” field was added to the “lock” and “set” CONFIG_CHANGE records. This should help provide some needed context for the audit event.
-
The filesystem type filter was expanded and now applies to all of the inode auditing code.
-
File capabilities are no longer recorded when unmounting a filesystem. This prevents a potential hang when unmounting a filesystem and due to the nature of the unmount operation, this should have little practical impact on the data recorded in the audit log.
-
Added support for file capabilities version 3.
UPDATE: Moved the MDP improvements to Linux v5.2, they were mistakenly included in the Linux v5.1 notes.
23 Apr 2019 tags: audit selinux Back in 2015 I started building Fedora Rawhide kernel packages with the SELinux and audit linux-next patches applied and making them available via a Fedora COPR repository. I did this both to try and make the SELinux and audit development work more accessible to people not familiar with patching and building kernels, as well as to help enable regular, automated testing of these development patches before they made their way into Linus’ tree. I spoke about this in more detail during a 2016 Flock presentation on Testing Bleeding Edge Kernels.
Now, almost four years after building the first of these kernels, I’ve reached a point where the entire process from generating a patched kernel SRPM, to testing the resulting kernel build is fully automated. Occasionally the system does require intervention to resolve patch merge conflicts, but those are surprisingly infrequent, and something that only needs to be dealt with once for each conflict. At some point in the future I’ll write up how everything works, but the plumbing is still a bit crude at the moment and I’d like to clean it up first. In the meantime you can look at my copr-pkg_scipts repository on GitHub, those scripts are the “smarts” for generating the patches from the development trees and creating the patched kernel SRPMs.
With everything in place, and working well for a few months, I want to make the results (both the kernel builds and the test results) available to a wider audience. However, as these are “bleeding edge” development kernel builds, I feel it is important to stress that these kernels are use-at-your-own-risk; they may be awesome, but they also may blow up in spectacular fashion and take your filesystem with it - be warned.
Kernel “secnext” Test Results
Those of you who wish to see the Fedora Rawhide kernel patches, the build notifications, and the test results, can find them on the kernel-secnext Google group:
The test system is a Fedora Rawhide VM that is fully updated prior to running the selinux-testsuite and audit-testsuite. Mellanox has kindly provided some InfiniBand hardware so that the SELinux InfiniBand tests can be run as well.
Kernel “secnext” Builds
Unfortunately, the Fedora COPR build system has been growing increasingly problematic for kernel builds over the past several years. Build times have been increasing to the point where eight hour builds are not uncommon, and the build chroot often breaks when Fedora Rawhide moves to the next release. While I really like the idea of COPR, I feel the reality of the Fedora COPR implementation is a disappointment for kernel builders. Because of this, in addition to the COPR builds, I’ve started building the kernel packages myself, you can find links to my YUM/DNF repository below. At the moment the repository has both x86_64 and aarch64 kernel packages, as well as the SRPMs. For those who prefer COPR, I will keep submitting the COPR builds, but I’m unlikely to spend any time resolving COPR specific build breakages.
14 Mar 2019 tags: seccomp It’s been over a year since the last libseccomp release (libseccomp v2.3.3 was released on January 10, 2018) but I’m happy to announce that today we’ve released libseccomp v2.4.0!
The libseccomp v2.4.0 release is a drop-in replacement for previous v2.x releases; no recompilation of applications is required. Although applications will need to be restarted to take advantage of the new libseccomp release.
The new release is a significant upgrade over libseccomp v2.3.3. In addition to a number of new features, there was a big push to improve the quality of the code in this release; a lot of time was spent adding new tests and fixing bugs. In fact there is one bug in particular that is worth giving specific mention: prior to the v2.4.0 release, libseccomp’s 64-bit syscall argument comparison code was incorrect and generated seccomp-bpf filters that would not always correctly match on syscall arguments. The impact of this bug should be relatively limited, but the researcher who identified this bug, Jann Horn, was able to identify libseccomp filters in systemd and Tor that were incorrectly generated due to this bug. Jann did not find any other vulnerable applications, but it is possible other applications are affected.
I would like to thank researches like Jann Horn who help identify problems in security critical applications and libraries like libseccomp, as well as the 46 people who have contributed their time, effort, code, and artwork to libseccomp (the complete list can be found in the CREDITS file) - thank you!
Changes in the v2.4.0 release include:
- Update the syscall table for Linux v5.0-rc5
- Added support for the SCMP_ACT_KILL_PROCESS action
- Added support for the SCMP_ACT_LOG action and SCMP_FLTATR_CTL_LOG attribute
- Added explicit 32-bit (SCMP_AX_32(…)) and 64-bit (SCMP_AX_64(…)) argument comparison macros to help protect against unexpected sign extension
- Added support for the parisc and parisc64 architectures
- Added the ability to query and set the libseccomp API level via seccomp_api_get(3) and seccomp_api_set(3)
- Return -EDOM on an endian mismatch when adding an architecture to a filter
- Renumber the pseudo syscall number for subpage_prot() so it no longer conflicts with spu_run()
- Fix PFC generation when a syscall is prioritized, but no rule exists
- Numerous fixes to the seccomp-bpf filter generation code
- Switch our internal hashing function to jhash/Lookup3 to MurmurHash3
- Numerous tests added to the included test suite, coverage now at ~92%
- Update our Travis CI configuration to use Ubuntu 16.04
- Numerous documentation fixes and updates
