Here’s an update on the main functional changes in security for the recently released 2.6.27 kernel.

• SELinux deferred mapping of filesystem contexts
  This patch by Stephen Smalley addresses the case where “alien” SELinux security labels need to be written to the local filesystem, for example, in the case of building RPMs where the local policy is different to the policy on the system where the RPM is to be installed. This will help with enabling SELinux on build systems (e.g. in the Fedora infrastructure) and more generally with packagers and ISVs shipping third party policy with RPMS.

  The way this works is to allow locally invalid labels to be written to disk by certain users (namely, those with the standard CAP_MAC_ADMIN capability and the mac_admin SELinux permission). For security purposes the system will treat those files as if they were not labeled, which means that no normal application will be able to interact with them. A further patch was added to allow administrators to view the alien labels.

• Show LSM mount options in /proc/mounts
  SELinux has several filesystem mount options specific to its security model, such as the ability to set security labels on a per-mount basis. This is useful for filesystems which do not have support for security labeling.

  These options were not being displayed in /proc/mounts, and Eric Paris wrote a patch which provides a general solution to this for all LSM modules with a new sb_show_options hook.

• Split proc ptrace checking into read vs. attach
  With this patch from Stephen Smalley, the core ptrace permission code was split so that read-only access to process state could be differentiated from access requiring full control of the process. Several applications such as lsof need to do things like read the memory state of a process, but nothing else, so, it is now possible to allow that without also allowing general ptrace access.

  The LSM ptrace hook is now passed a flag, either PTRACE_MODE_READ or PTRACE_MODE_ATTACH, to allow the security modules to differentiate access in policy, if desired.

• Removal of LSM dummy module
  Ever since the introduction of LSM, a ‘dummy’ module has always been the default when LSM was built but not configured with a specific security model. This has never been a good default, as people almost certainly need the capability module.

  Miklos Szeredi supplied a patch to remove the dummy module and ensure that the capability module is always compiled in as the default. With the capability code always compiled in, LSM was then further simplified to remove the secondary module stacking code. This was previously used by LSMs such as SELinux to dynamically stack capabilities, and now that it is known that capabilities is always there, this stacking can be performed by simply calling directly into the capability module.

• Protect legacy applications from executing with insufficient privilege
  Andrew Morgan authored a patch to ensure that certain applications which are not granted all of the privileges they request or expect have their execution failed with EPERM. The counter-intuitiveness of this should be a hint as to the overall complexity and subtlety of OS security. The full background to this change is documented in this sendmail capabilities war story. If your brain doesn’t explode when you read that, there is something wrong with you and you should probably be working in computer security, if not already.

  Filesystem capabilities were also promoted from experimental status in the kernel configuration to a standard option, and are indeed now enabled by default on at least one distribution (Fedora 10 development).

• Fix setting of PF_SUPERPRIV by __capable()
  David Howells fixed a long standing bug in the capability code, where the PF_SUPERPRIV flag could have been set inappropriately on processes which were being probed for a privilege rather than actually using the privilege. This flag is set on a process when it exercises privilege (e.g. via capabilities), and may be later used for process accounting purposes. David’s patch fixed the problem by cleanly demarcating the probing of capabilities vs. using them, resulting in a nice general code cleanup.

Upcoming changes

There’s quite a lot coming up in security for the next couple of kernels, with major changes including David Howells’ epic credentials API rewrite (which touches pretty much everything and is thus moving very slowly upstream), the Integrity framework and IMA from Mimi Zohar et al, and Trusted Boot (TXT) from Intel. It’s not clear whether these will make the current merge window for 2.6.28, although some preparatory patches are already merged. Paul Moore has been doing a lot of work on labeled networking, which is maturing in terms of government/military requirements, and should also provide some very interesting functionality for general users down the track. There’s been an updated code drop for Labeled NFS, although I’ve not yet had a chance to give it a detailed review (things get busy upstream when you combine KS/LPC and a kernel release). There are also possible merges of TOMOYO and AppArmor if the VFS pathname issue is resolved.