The talk seemed to go reasonably well, and had a larger audience than I expected given that Tridge and Willy were talking at the same time. A video of the talk should appear online soon.
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.
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).
Talks I hope to see include:
- AIO: Why is this so hard? (Zach Brown)
- Using a Malicious User-Level RCU to Torture RCU-Based Algorithms (Paul McKenney)
- Geek my Ride (Jon Oxer and Jared Herbohn)
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.
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.
- Dummy SELinux policy support
Serge Hallyn added a dummy policy for SELinux to the kernel tree. This is useful for testing SELinux and a base for building minimal and experimental security policies.
- Bouned per-thread security contexts for SELinux
KaiGai Kohei submitted a patch which allows different threads in a process to be labeled with distinct security contexts. Such threads are guaranteed to not exceed the security policy permissions of the parent process. This is part of his work in extending SELinux to the web application stack, and in this case, is aimed at constraining in-process web server scripts (e.g. mod_python applications).
- Labeled networking updates
Paul Moore provided a series of updates to the Labeled networking subsystem, which he promises to document on his blog.
- MAC policy for privilege in Smack
Casey Schaufler extended Smack so that MAC policy may be used to limit the use of privilege. Previously, the Smack model maintained strict orthogonality between privilege and access control, where privileged processes were exempted from MAC policy enforcement. This feature allows for MAC policy enforcement of processes running with specific security label (as written to
/smack/onlycap), or for all processes if the
onlycaplabel is specified as ‘*’.
- TPM updates
Rajiv Andrade provided several updates for the TPM driver.
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.