Monthly Archives: October 2008

Upcoming conference talks on SELinux applications: sVirt and Kiosk Mode

Recently, I’ve been busy getting the initial cut of sVirt out, and am currently processing community feedback before issuing an update. The basic idea behind sVirt is to apply MAC label security (SELinux, Smack etc.) to Linux-based virtualization schemes such as KVM, allowing the existing OS-level security mechanisms to be re-used for process-based VMs. This is an application one of the core advantages of Linux-based virtualization, where generally, all of the Linux process management infrastructure within the kernel and wider OS may be applied to domains which run inside Linux processes. So, for MAC label security in this case, we don’t need to do anything in terms of modifying kernel security mechanisms, and simply modify security policy as desired. We can focus on developing the appropriate high-level abstractions (e.g. management tool support) rather than developing a new security mechanism.

How can this be useful? In the simplest case, we can increase isolation between virtual machines by assigning them different security labels, and enforcing a MAC policy which prevents them from interacting. This helps ameliorate the increased risk arising from running domains on the same hardware where previously they may have been physically separated on different machines. This is just a start. There are plenty of interesting things which can be done once the core functionality is in place, although the initial idea is to simply provide stronger isolation to better protect domains from each other.

At an architectural level, security labeling support is being added to libvirt, a virtualization API which abstracts various aspects of virtualization including different hypervisor types, storage, networking, and with sVirt: MAC security. With sVirt integrated at the API level, security labeling support can be integrated into high-level tools via standardized and flexible abstractions. For example, when creating a new domain, the graphical virt-manager tool may include a checkbox to designate the domain as “isolated”—or perhaps just do it by default for true zeroconf.

I’ll be introducing sVirt more completely at LCA next January, so if you’re marching south and have interests in both security and virtualization, it might be worth popping in. I’m up against Tridge in the timeslot, so it might be an intimate session.

Next week, I’ll be giving a talk on Fedora Kiosk Mode at Malaysia’s inaugural developer conference, FOSS.MY. Kiosk Mode is another high-level MAC security application, where anonymous users can safely access desktop sessions and browse the internet. If you have the xguest package installed, it Just Works, as people are starting to notice.

I’ve been shortlisted on the same topic at the revamped FOSS.IN a few weeks later. There’s also been some discussion of a kernel development workout session, in which I’d love to participate, although it’s not yet short-listed. There’s also the FUDCon attached to FOSS.IN. We’re hoping to have a Fedora box there running Kiosk Mode for people to play with.

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_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.

Foss.in 2008: taking no prisoners

It seems that foss.in this year is undertaking a major change in its focus—away from the traditional general conference and toward a developer-oriented working event.

Atul Chitnis today posted a detailed rationale, which has also been summarized by Sankarshan. It seems that inspiration was drawn from the recent Plumbers Conf, and also the strong desire to foster actual FOSS development in India.

A FUDCon is being held in conjunction with foss.in, which should also help attract developers. It’s the closest upcoming FUDCon to me in geographic terms, and I’m working on attending for that at least.

From discussion with some of the folk involved in the wider event, it seems that many fine details are yet to be worked out, and while the emphasis is very much on Indian developers, I’d suggest that international developers who’ve been considering submitting a proposal this year definitely still do so.