SELinux and Security changes in the 2.6.27 Kernel
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_ADMINcapability and the
mac_adminSELinux 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
- 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
lsofneed 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.
ptracehook is now passed a flag, either
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_SUPERPRIVflag 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.
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.