I’m on my way back to Sydney from Kuala Lumpur, following FOSS.my, Malaysia’s first major grassroots FOSS conference. Amazingly, Colin Charles and the team managed to organize the event from scratch in six weeks, attracting two full days worth of regional and local speakers.

If ever a whiteboard needed a “do not erase” sign, this would be it.

Based loosely on the formats of similar conferences in India and Australia, this first effort for SE Asia seems to be off to a great start, and I think we can expect an expanded event next year. The keynotes were all very interesting, and I especially appreciated being able to learn about all the various FOSS issues and efforts in Malaysia.

Several side-sessions ran in parallel with the main talks, where rooms were provided for projects including Ubuntu, Fedora and FOSSChix.my, the latter featuring sessions led by Pia Waugh and Pamela Fox. There were quite a lot of lightning talks, which I think were probably the most fun to attend, perhaps apart from the speakers dinner in the nightclub area of KL.

FOSSChix.my side session.Jaya Kumar closed out the conference with a thought-provoking keynote, covering some issues he’s faced in his local community, and reminding us to ensure that we need to be vigilant in confronting instances of prejudice in all of our online communities.

The hallway track, five stories up.I gave a talk on the Anatomy of Fedora Kiosk Mode, the slides of which can be downloaded here. There’s also more photos.

It was great meeting everyone, and I hope to be back again next year.

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.

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.

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.

Today was the last day of the Linux Plumbers Conference, which overall seems to have gone really well. Certainly it exceeded my expectations, which were already pretty high. In my view, the conference was distinctive in that it was totally developer-focused and collaborative, with no thinly-disguised marketing talks.

The atmosphere was relaxed, and not overly structured, which allowed for a lot of useful ad-hoc discussions between developers working in different areas of the OS. An example was Arjan’s talk on achieving a five-second boot, which itself was very interesting and entertaining, but was also followed by a lunch session with a bunch of distro maintainers to work out various specifics. It seems that a small arms race has been launched between Fedora & Ubuntu on who can first get the default install to a five second boot.

I was interested to catch up on the latest file system developments, and caught the updates on btrfs and crfs by their respective authors, Chris Mason & Zach Brown. The disk format for btrfs will be locked in before the end of the year, according to Chris, to encourage more developers and users to start playing with it. crfs is looking increasingly impressive as a small-scale, fast, reliable and sane networked file system: I grabbed a photo of the slide comparing it with other network filesystems:

Other photos I took at the conference are here.

It was really great to catch up with so many people I work with over the net, and also finally meeting some people I must have known for more than a decade but still never met in person — possibly due to this being the first Linux conference I’ve attended in the US.

During the closing, Kristen Accardi did a brief survey on several aspects of the conference, and it seems that virtually everyone was happy with it. I think the conference has a bright future, as it seems to have filled a now obvious need for a place where a cross-section of mainline Linux developers can meet up specifically to solve problems.

It turns out I was able to make it to Linux Plumbers Conference, after another last minute change of circumstances, and I’m in fact in Portland.

Regretfully, it turns out I won’t be able to attend the Linux Plumbers Conference next week in Portland OR. This means I have a surplus transferable conference registration (currently costing $300).

If you’re an established FOSS community developer who is otherwise unable to obtain funding for registration, shoot me an email. I’ll transfer the ticket at no cost to whoever makes the first appropriate request.

Following up on a couple of the comments on my last entry on SELinux memory protections vs. Zend Optimizer:

The policy does indeed look like it was generated automatically by audit2why or similar. This very clearly highlights a core problem with “learning mode” security schemes, which can blindly encapsulate dangerous behavior in a buggy application, or even an attack in progress. This issue was previously expounded by Josh Brindle in Status Quo Encapsulation.

Such techniques do have their place, although it is always recommended that such resulting policy be reviewed. Again, it is easy to find help.

It’s unfortunate that some vendors promote automated policy generation schemes as a core usability feature, leading many people to assume that this is a great idea, and even the way things are supposed to work.

Of course, nobody would ever capitalize on peoples’ combined fear and lack of expertise in an area and sell a “miracle” solution which doesn’t quite work. No, that would never happen.

As H.L. Mencken and some character on the single episode of CSI I suffered through said: “… there is always an easy solution to every problem — neat, plausible and wrong.”.

The idea that the problem of OS security can be solved effortlessly with the click of a mouse should be raising alarm bells in everyone’s heads by now, surely ?

I don’t know what a Zend Optimizer is, but it apparently does not play well with SELinux. I’ve encountered a blog entry by someone who has tried to do the right thing and keep SELinux enabled, after finding the code for a policy module which makes this stuff work.

I was surprised when I saw the source of the module, which includes:

allow httpd_t self:process execstack;
allow httpd_t self:process execmem;
allow httpd_t self:process execheap;
allow httpd_t usr_t:file execute;

When loaded, this will enable the web server to execute memory on its heap, stack or certain types of executable memory allocated via mmap(2). These are well-known attack vectors and disable some very important memory protection mechanisms. See Ulrich Drepper’s SELinux Memory Protection Tests for details.

The file execute permission is also very concerning, as it allows the web server to execute generically labeled user files. Combined with disabled memory protections, and third-party software using unsafe memory execution techniques, I’d recommend being cautious about deploying this solution.

What I would suggest, if you don’t understand the security policy, is to run it by your nearest SELinux community. Many mailing lists and IRC channels exist where people will be able to help: see User Resources from the SELinux Project Wiki.

It’s important to note that whatever this code is supposed to be doing (apparently, dealing with some form of source code obfuscation), techniques such as making a stack executable are inherently insecure and should never be necessary.

SELinux really is trying to help you here, and free expert advice is merely an email away. At the very least, someone will be able to explain what the risks are, and help you make an informed decision on how to proceed: perhaps it will be better for your particular requirements to allow certain accesses rather than disabling SELinux for the entire system. And if the code is not trying to do something dangerous, an SELinux developer may write a simple module for you to load to work around the issue.

I’ll be attending the Linux Plumbers Conference in Portland OR a few weeks from now. It seems like a really useful event for developers, and even a little unusual in that Linus will be giving a git tutorial.

If there’s anyone attending who’d like to meet up & discuss SELinux, especially distro integration issues and similar, let me know. Kees Cook from the Ubuntu project will be there, so if we have enough people, it might also be worth organizing a BoF session (it seems there are currently slots available).

Similarly, if anyone is interested in discussing the integration of MAC security with KVM (i.e. sVirt — a project I’ll discuss in more detail soon), also let me know.