What’s new and exciting with SELinux and security in the new 2.6.26 kernel? Expanding some of the items from the excellent Kernel Newbies 2.6.26 page:

• security= boot parameter
  This patch by Ahmed Darwish allows a particular security module to be selected at kernel boot time, so that distributions can ship multiple security modules and allow the user to decide which one (if any) to enable. For example: security=selinux selects SELinux, while security=smack selects SMACK. (In Fedora, you don’t need to do anything: SELinux is the default).
• New SELinux open permission
  Until now, opening a file under SELinux invoked the same permission checks as the intended operation on the file, such as read, write, execute and append. There was no separate “open” check: opening a file for write, for example, was considered by SELinux policy as equivalent to actually writing to the file. Experience has shown that this approach is not ideal for handling cases such as IO redirection via the shell, because policy writers cannot usefully guess where users will send redirected output. This is a very common use-case for Linux, so a solution is most definitely necessary, while also preserving strong security. Can it be done? Yes!

  Implemented by Eric Paris, the new open permission provides a way to address the issue by providing applications with liberal access to read/write/execute/append permissions but tightly locking down the ability to open a file. In the case of redirecting output via the shell:

  bash# /sbin/do-stuff > /tmp/output

  the shell forks and creates /tmp/output, calls dup2(2) to replace stdin with the newly created file descriptor, then execs do-stuff. With the old permissions, do-stuff would have required an SELinux write permission on the new file, which it very likely would not have had. By providing do-stuff with liberal file access permissions, but not the new open permission, its output may now be redirected to the file without needing to give it the ability to directly open the file. The invoking shell of course needs the open permission, which it effectively delegates to do-stuff via the open file descriptor.

  Updated security policy which utilizes this technique should be available soon in rawhide, and integrated into Fedora 10, providing significant usability improvements for sysadmins and power users.

• Permissive Types
  Also implemented by Eric, permissive types (aka permissive domains) allows permissive mode to be selected on the fly on a per-domain basis. Permissive mode is where security policy is being checked and logged, but not actually enforced, and was previously only possible on a system-wide basis. By making this per-domain, applications which are experiencing SELinux policy issues may be flipped into permissive mode, allowing them to do what they need until a proper fix is available, without disabling policy enforcement for the rest of the system.

• Network Port SID Cache
  Paul Moore implemented a cache to improve the performance of the SELinux networking code, so that network port labels are no longer looked up in the (typically large) kernel policy database on a per-packet basis, and is instead retrieved from an RCU-based cache. This addresses a long standing network performance issue which has been observed with very high loads on network servers.

There’s quite a lot happening in security for 2.6.27, some of which has already been merged into Linus’ tree. Due to the pervasive nature of some of the patches (including David Howells’ credentials rework), I’m feeding all of the SELinux stuff via my security-testing tree. The “devel” branch is where bleeding edge changes are initially stabilized before being applied to the “next” branch, which is in turn fed into to linux-next.