The sVirt code has now been merged into the upstream libvirt repository (git mirror). Thanks to Dan Walsh for taking on the remaining userspace development, and Daniel Berrange and the rest of the libvirt folk involved for reviewing and improving the code.
While we’ll be focusing on the SELinux driver for sVirt, a really useful and cool project for someone interested in security and virtualization would be to develop a SMACK driver.
With the recent news of multiple vulnerabilities in Adobe flash and PDF software, folk running Fedora 10 may wish to consider using SELinux to confine browser plugins.
Dan Walsh has previously implemented SELinux lockdown for browser plugins via nspluginwrapper, as discussed here. Unfortunately, this has been disabled by default, due to a clash with the mozplugger package, which uses nspluginwrapper to launch applications inside the browser.
Personally, I’m happy to have OpenOffice or similar open up in a separate window, using the standard Firefox mechanism for doing so, especially if it means I’m able to keep browser plugin confinement enabled.
Here’s what I did:
# yum remove mozplugger
# setsebool -P allow_unconfined_nsplugin_transition=on
# setsebool -P allow_nsplugin_execmem=off
# setsebool -P nsplugin_can_network=off
This of course removes mozplugger, but I don’t seem to need it. When downloading a PDF, for example, Firefox prompts if I want to open it with evince, and provides me with an option to always do that without further prompting. YMMV.
The setsebool commands change several nspluginwrapper options in SELinux, while the -P option ensures that the changes persist across reboots (see setsebool(8)).
Detailed explanation:
allow_unconfined_nsplugin_transition ensures that nspluginwrapper transitions to a new security label when running a plugin, so that special security policy can be applied to it. This is required for any useful effect.allow_nsplugin_execmem ensures that memory protections are being enforced to prevent plugins from executing code on the stack and in mapped memory.nsplugin_can_network prevents plugins from connecting to anything other than reserved ports. Apparently, this may upset some flash code which wants to call home (you’d be surprised how much of this goes on, or perhaps not), so you may want to leave this as-is, or at least keep an eye on the messages from setroubleshoot.Note that if you do run into problems, you can put SELinux into permissive mode rather than disabling it, which will at least provide some useful logging information (and feel free to post questions to the fedora-selinux-list).
Btw, here’s how to configure SELinux for permissive mode:
System -> Administration -> SELinux Management
Set ‘System Default Enforcing Mode’ to ‘Permissive’
And you’re done.
A bugzilla ticket has been opened on the issue of finding a long-term solution which allows both mozplugger and plugin confinement to co-exist, but unfortunately, users currently need to decide whether they prefer increased security or a more Windows-like experience, with the latter as the default.
Some videos from LCA 2009 have been posted online, per this email from Mary Gardiner.
The video from my sVirt (MAC security for Linux virtualization) talk is available as an OGG file. I’ve also re-uploaded it as a google video.
LCA was a genuinely enjoyable conference: laid-back and really well organized, with a good balance of talks. One really great aspect was the way internet access was provided to the accommodation, which at least in my case, worked perfectly, with a microwave link from UTAS connected to the hotel’s internal wiring. I often need to work during conferences, and having good network access is probably my top priority in selecting accommodation.
I was glad to be part of the security miniconf organized by Casey Schaufler, which brought together folk from the kernel security community and various highly technical folk. There were talks from several leading security developers, including Casey (fs capabilities and rootless systems), Russell Coker (standing in for Kaigai Kohei on SE-postgresql and web application MAC), and Kentaro Takeda (TOMOYO). The miniconf concluded with an open panel discussion which was covered by LWN. For reasons I can’t quite recall now, I ended up doing an ad-hoc presentation on Fedora Kiosk Mode, which I think helped demonstrate some of the progress SELinux has made in terms of usability and extension to general use scenarios.
Also see my flickr photoset, and a short video of one of the exhibitions from the Batteries Not Included art exhibition, which ran as part of the conference.
LCA 2010 will be held in Wellington, New Zealand — here’s an amusing video by the organizers. I hope to make it there.
I’ve finally found reliable workarounds for a long-standing issue where my Intel MacBook doesn’t work with most projectors.
The error message when trying to use xrandr to force output via VGA looks like:
$ xrandr --output VGA --auto xrandr: cannot find crtc for output VGA
It seems the driver has a bug where it thinks it has the hardware available to drive the LCD panel, DVI and analogue VGA outputs at the same time, when it can in fact only handle two of these. xrandr shows three displays enabled:
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1280 x 1280 VGA connected (normal left inverted right x axis y axis) 1024x768 60.0 800x600 60.3 640x480 59.9 LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) 286mm x 179mm 1280x800 59.9 + 1024x768 60.0* 800x600 60.3 640x480 59.9 TMDS-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0* 800x600 60.3 640x480 59.9 TV disconnected (normal left inverted right x axis y axis)
I’m guessing this might have something to do with both analogue and digital signals being sent out the same connector. In any case, the fix is to disable ‘TMDS-1’.
This can be done during an active session:
$ xrandr --output TMDS-1 --off $ xrandr --output VGA --auto
The X server can also be configured to disable ‘TMDS-1’ during startup. On F10, you need to first create an xorg.conf. I ended up doing this:
# yum install system-config-display # system-config-display
and just quit, which seems to cause /etc/X11/xorg.conf to be generated.
I edited the file, adding the “Option” line to the “Device” section:
Section "Device" Identifier "Videocard0" Driver "intel" Option "monitor-TMDS-1" "dvi" EndSection
then, I added this section:
Section "Monitor"
Identifier "dvi"
Option "Disable" "true"
EndSection
which all seems to work ok for me and is about as obvious as quantum supergravity.
LCA has been great fun so far — more later.
I’m preparing to travel to Hobart for LCA next week, which will be a refreshing break from the 40° heat in Sydney, and from conference jet lag—this will my first same-timezone conference in a couple of years, and the closest I’ve ever been to Antarctica.
I’ll be giving a talk on sVirt, a project to harden Linux-based virtualization with MAC security. From the abstract:
With increased use of virtualization, one security benefit of physically separated systems — strong isolation — is reduced, an issue which may be ameliorated with the application of MAC security (e.g. SELinux, SMACK) in the host system.
For example, a flaw in the hypervisor or errant misconfiguration of the host may allow a virtualized guest OS to “break out” into the host environment and compromise other guests. By applying MAC security to virtual machine instances at the host level, such threats may be mitigated through strong isolation and containment of guests.
If you think hypervisor flaws are merely some kind of theoretical threat, you’re dreaming. A large number of folk seem to be entirely unware of virtualization security issues, according to Joe Hernick of Network Computing:
To find out how prepared our readers are, we fielded a survey—and got some eye-popping results. We can’t help thinking that the 43% saying they feel virtualized machines are just as safe and secure as traditional environments are whistling past the graveyard. Of the 384 IT operations and security professionals responding, a mere 11% have put formal strategies in place to protect their VMs.
Hyperbole aside, people who are deploying virtualized systems definitely need to start thinking about this stuff.
The sVirt project is currently in initial development, with the aim of making a v1.0 release shipping this year in Fedora. A key feature of the initial release will providing simple MAC isolation of KVM domains, so virtualized systems can’t attack each other or the host system.
While Dan Walsh gave an ad-hoc talk on the subject last week at Fudcon in Boston, and I gave an ad-hoc lightning talk at Foss.my, this will be the first planned presentation properly outlining the goals, architecture and implementation strategy; and how this is part of extending flexible MAC security across every level of the modern application stack from the local OS to the globally distributed environment (cloud, grid et al). There’s no shortage of interesting and bizarrely difficult problems to solve in this area. Or buzzwords.
LCA looks to be a fun conference this year, if not perhaps a little subdued due to the economic crisis (and hopefully nothing to do with Tasmania being the world’s leading producer of pharmaceutical opiates).
I expect to be attending the Linux Kernel and Security miniconfs.
Talks I hope to see include:
The organizers have just announced mystery prizes for folk registering in the final week, so if you’re yet to decide whether to attend, there’s some more encouragement.
Frankly, with the current economic situation, I would consider attending a top-notch FOSS conference like this a priority in terms of useful things to do to bolster your career.
This is to announce a kernel security subsystem wiki, supported by the kind folk at kernel.org. It’s intended for use by community developers and users of kernel security projects. So far, there are sections on working with the security-testing git repo, a listing of various kernel security projects, and an events page. If there’s something you’d like to see or change on the wiki (particularly if it relates to your own project), create an account and make it so.
Note that this wiki is not related to security response: the security incident contact for the kernel per the MAINTAINERS file is security @ kernel.org.
Version 2.6.28 of the Linux kernel was released during Christmas, so I thought it’d be worthwhile waiting until after typical vacation days to post a summary of changes to the security subsystem. As always, thanks to the Kernel Newbies folk who track major kernel changes.
/smack/onlycap), or for all processes if the onlycap label is specified as ‘*’.This was not a terribly exciting release for the security subsystem.
Thus far for the 2.6.29 kernel, the main change is the massive credentials API change from David Howells. This has caused a couple of regressions, which were picked up by subsystem testing of Linus’ tree. Fixes have been developed and are currently partially merged upstream. It seems we need to get more testing done in linux-next to avoid such breakage during future merge windows.
Also noteworthy is the merge of the pathname security hooks for LSM, which should pave the way for TOMOYO and AppArmor in 2.6.30, subject to the general patch submission review process. TOMOYO is only a couple of acks from approval, has been baking in -mm, and is pretty much self-contained. It may even appear in 2.6.29 if the merge window is open for features long enough.
If you’re interested in tracking commits to the security testing tree, you can now do so via identica.
Commits to the master git repo are sent via gregkh’s bti, using the following script as the $repo/hooks/post-receive hook:
#!/bin/bash
read oldrev newrev refname
short_refname=${refname##refs/heads/}
/usr/bin/git rev-list $oldrev...$newrev --no-merges --pretty=format:"%h|%ae|%s" --abbrev-commit | grep -v ^commit |
while read a; do
echo "$short_refname|$a" | cut -f-140 | ~/bin/bti
sleep 1
done
It may not scale too well, but it’s simple. Suggestions for improvement are welcome.
Unrelatedly, here’s a short video I took of a long train in Bangalore:
Some observant folk may have noticed that I’m now listed as the kernel security subsystem maintainer. This came about as a result of the growing number of security projects headed upstream, and recent comments from Linus and Andrew about the lack of a clear security maintainer. In some ways, this is a formalization of the role I’d been performing with the security-testing tree, although of course the workload and responsibility levels will increase.
I’d like to thank Chris Wright, Casey Schaufler and Stephen Smalley for their endorsements and support in this, and I’m expecting that all in the kernel security community will continue forward in a collaborative approach. I consider previous discussions on architecture resolved.
For new security components being proposed for upstream merge, I’d like to generally follow the protocol outlined by Arjan van de Ven and summarized at KernelTrap: Documenting Security Module Intent.
Essentially, any new security project—not limited to LSMs—should be accompanied by a clear and concise document outlining its requirements and expected uses. This is to allow both security and regular folk to perform review of the code in terms of how it meets the specified requirements, and to avoid getting bogged down in unresolvable discussions about the project’s security model.
A good example of how such an approach has helped is with the recent anti-malware scanning project, which rapidly went from zero to hero in a few weeks following elucidation of design goals. The project now has buy-in from several core developers and has led to fsnotify, a unification and overhaul of the various filesystem notification schemes in the kernel.
The design document does not need to be a novel: a page or two should be enough, and certainly as much as you’d expect upstream developers to read first-up.