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
06 Mar 2019 tags: audit selinux Instead of Linux v4.21, Linux v5.0 was released on March 3, 2019. The major version bump doesn’t reflect any major changes, other than there were a “lot” of v4.x releases and Linus decided it was time to increment the major version number.
The SELinux and audit kernel highlights are below.
SELinux
-
Rework the internal SELinux label database (sidtab) to improve both availability during policy reloads and lookup performance. This should generally improve SELinux performance as well as reduce SELinux related ENOMEM errors during a policy reload.
- The SELinux filesystem mount controls have changed to always allow filesystem submounts. For all current in-tree filesystems, granting permission to mount submounts should not degrade the security of the system, and brings the SELinux access controls more in line with the kernel’s capability checks for submounts. As Ondrej Mosnacek explains in the patch description:
… In the current kernel tree, the MS_SUBMOUNT flag is set only via vfs_submount(), which is called only from the following places:
- AFS, when automounting special “symlinks” referencing other cells
- CIFS, when automounting “referrals”
- NFS, when automounting subtrees
- debugfs, when automounting tracefs
In all cases the submounts are meant to be transparent to the user and it makes sense that if mounting the master is allowed, then so should be the automounts. Note that CAP_SYS_ADMIN capability checking is already skipped for (SB_KERNMOUNT|SB_SUBMOUNT) …
-
Internal kernel changes to support the internal VFS mount API changes. These changes should have no impact on the SELinux policy or user experience.
- A number of internal kernel bug fixes relating to error handling and policy byte ordering.
Audit
-
System call auditing support was added to the RISC-V architecture.
-
The file capabilities fields, the “cap_f*” fields in the PATH record, have been shortened to log only a value of “0” when none of the capabilities are set. This should help shorten PATH records on systems that don’t make use of file capabilities.
-
Fixed a problem where empty arguments were not being properly logged in the EXECVE record.
-
A large number of fixes to the audit subsystem’s use of fsnotify. This should help improve the performance and robustness of audit’s filesystem watches.
-
Removed the CONFIG_AUDIT_WATCH and CONFIG_AUDIT_TREE kernel configuration options, using the CONFIG_AUDITSYSCALL option instead, and forcing the CONFIG_FSNOTIFY option when CONFIG_AUDITSYSCALL is enabled.
-
A number of internal code cleanups.
