Kernel Repository Process

Update: new process defined here

Just as the software changes over time to better serve our needs, so should our processes. Starting with the upcoming merge window, I’m changing the process used to manage the SELinux and audit repositories. The new approach is described below:

1. When it is time to send a pull request upstream (approximately one or two RC releases before the merge window for SELinux, during the merge window for audit), copy the next branch of the repository to a new branch, stable-X.YY, such that X.YY matches the version of the upcoming release. Send the pull request using the new stable-X.YY branch.

2. Rebase the next branch:
   • In the case of SELinux, rebase the next branch against the linux-security/next branch. It tends to be common practice for the linux-security/next branch to be rebased on a semi-regular basis against Linus’ X.YY-rc1 or X.YY-rc2 release, as a result the SELinux next branch may need to be rebased outside the regular merge window cycle.
   • In the case of audit, rebase the next branch against Linus’ latest stable release, the kernel release that started the merge window.
3. Accept patches into the stable-X.YY and next branches as appropriate during the development cycle. Send stable-X.YY patches upstream as soon as they have been reviewed and verified against the appropriate test suites. Continue until it is time to send the next pull request upstream.

For reference, the old process was defined here.

Libseccomp 2.3.0 Released

We’ve just released a new version of libseccomp, libseccomp version 2.3.0. The libseccomp library provides an easy to use, platform independent interface to the Linux enhanced syscall filtering mechanism.

• https://github.com/seccomp/libseccomp/releases/tag/v2.3.0

This new version of libseccomp builds upon the previous release and should be a drop-in replacement for the 2.x releases. All users are encouraged to upgrade to the new version at their earliest convenience.

Changes in the 2.3.0 release include:

• Added support for the s390 and s390x architectures
• Added support for the ppc, ppc64, and ppc64le architectures
• Update the internal syscall tables to match the Linux 4.5-rc releases
• Filter generation for both multiplexed and direct socket syscalls on x86
• Support for the musl libc implementation
• Additions to the API to enable runtime version checking of the library
• Enable the use of seccomp() instead of prctl() on supported systems
• Added additional tests to the regression test suite

Finally, thank you to everyone who has submitted suggestions, provided testing help, and contributed patches to the project.

Audit Filtering on Executable Pathname

As part of Linux 4.3 we added the ability to selectively filter based on an executable pathname and not just the executable’s current PID. This post is a quick introduction to the new functionality using ‘/usr/bin/echo’ as a simple example.

In order to use the new audit by executable functionality you need to make sure you are running Linux 4.3 or greater, and the audit userspace tools version 2.5 or greater. For this example I’m using a Fedora Rawhide system with a Linux 4.5 development kernel and the audit v2.5 userspace.

# uname -r
4.5.0-0.rc3.git0.1.secnext.1.fc24.x86_64
# rpm -q audit
audit-2.5-1.fc24.x86_64

First, I’m going to clear any existing audit rules from the system and create a new rule to generate an audit event whenever the ‘/usr/bin/echo’ application calls the write() system call; I’m also going to have the kernel mark these records with the ‘testing’ key for easier parsing by ‘ausearch’ later. It is important to note that this is just a simple example to demonstrate the functionality, the new ‘-F exe=…’ audit filter can used as part of larger, more complex rules.

# auditctl -D
# auditctl -a always,exit -F arch=b64 -S write -F exe=/usr/bin/echo -k testing

With the new rule loaded into the kernel we simply need to execute ‘/usr/bin/echo’. It is important to specify the full path for the echo command as some shells, including bash, default to a built-in if an absolute executable path for echo is not given.

# /usr/bin/echo "hello world!"

We can now check the audit log to see if any events have occurred that match the ‘testing’ key we used when we created our new audit by executable rule.

# ausearch -i -k testing
----
type=CONFIG_CHANGE msg=audit(02/12/2016 16:41:00.931:160) : auid=root ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op="add_rule" key=testing list=exit res=yes 
----
type=PROCTITLE msg=audit(02/12/2016 16:41:08.347:161) : proctitle=/usr/bin/echo hello world! 
type=SYSCALL msg=audit(02/12/2016 16:41:08.347:161) : arch=x86_64 syscall=write success=yes exit=13 a0=0x1 a1=0x561daea04030 a2=0xd a3=0x561daea04030 items=0 ppid=881 pid=1057 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=2 comm=echo exe=/usr/bin/echo subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=testing

In this case we see two audit events have been recorded in the audit log. The first event consists of a single CONFIG_CHANGE record and was generated when we loaded the new rule into the kernel. The second event was generated by our newly created audit by executable rule and show ‘/usr/bin/echo’ using the write() syscall. For such a simple application as ‘/bin/true’ this is exactly what we would expect, and an indication that everything is working correctly.