I had a couple of hours spare, so I put together a set of Perl bindings
for libvirt. I’m currently calling the module Sys::Virt which seems to
be the most appropriate location in the CPAN namespace, but I’m open to
suggestions if people think that sucks. I’ve currently got near 100%
coverage of the C APIs, but not exposed all the static constants yet.
There are a couple of trivial example programs illustrating use of the
API for extracting info about domains.
For now you can grab a snapshot of the source for the binding using
Mercurial from the URL http://hg.berrange.com/libraries/sys-virt/. When I’ve tested it more completely I’ll upload it to CPAN.
I’ve just read Dan Walsh‘s latest in a long series or articles on SELinux and am very excited to hear about both the new modular SELinux policy and the introduction of the semanage tool.
Good times for administrators
Since the initial debut of SELinux in Fedora Core 2, great progress has been made in ensuring that all applications distributed in core operate correctly when SELinux is enabled. The bug-bear for administrators, however, has been the situations where they have to make customizations not anticipated by the engineers writing the policy. The the simple example of changing Apache to also listen on port 8001, as well as the usual port 80, has always been much harder than it ought to be. It would typically require downloading the policy module sources, finding the place to add in the extra port definition, re-building the binary policy module and finally loading it into the kernel. With soo much work required for a simple change of port number, it is not so surprising that SELinux can cause much frustration for administrators. This has unfortuntately reflected negatively on SELinux as a whole – I say unfortunately, because at the end of the day this is really just a tools problem – not a technology problem. With the arrival of Fedora Core 5, I am very happy to see that the new semanage tool has dramatically changed this situation for the better.
Going back to my example of changing Apache to run on port 8001. If we edit httpd.conf at this time to change ‘Listen 80’ to ‘Listen 8001’ & restart apache, we ought to see it fail to start because port 8001 is not a normal Apache port:
# sed -e 's/Listen 80/Listen 8001/' /etc/httpd/conf/httpd.conf
# /etc/init.d/httpd restart
Stopping httpd: [ OK ]
Starting httpd: [FAILED]
# tail /var/log/audit/audit.log
type=AVC msg=audit(1142888562.766:5739): avc: denied { name_bind } for pid=12524 comm="httpd" src=8001 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1142888562.766:5739): arch=c000003e syscall=49 success=no exit=-13 a0=5 a1=5555556ac660 a2=10 a3=7ffffff0c8fc items=0 pid=12524 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" exe="/usr/sbin/httpd"
type=SOCKADDR msg=audit(1142888562.766:5739): saddr=02001F41000000000000000000000000
The manpage says that the ‘-l’ argument to semanage will list the configuration for the different types of managed object – files, ports, users, etc. So to see what ports the current policy allows for apache lets try looking for anything related to ‘http’ (if you don’t know what type to look for double-check /var/log/audit/audit.log):
# semanage port -l | grep http
http_cache_port_t tcp 3128, 8080, 8118
http_cache_port_t udp 3130
http_port_t tcp 80, 443, 488, 8008, 9050
A quick glance at this output shows that the http_port_t type is the one of interest to us. The ‘add’ command to semanage allows this list of ports to be extended, so lets add port 8001 & verify that it has updated the policy
# semanage port -a -t http_port_t -p tcp 8001
# semanage port -l | grep http
http_cache_port_t tcp 3128, 8080, 8118
http_cache_port_t udp 3130
http_port_t tcp 8001, 80, 443, 488, 8008, 9050
So, now try starting apache again:
# /etc/init.d/httpd start
Starting httpd: [ OK ]
So no more need to interpret, edit & re-compile obscure policy files, just run single command and Apache is all set to listen on port 8001. Good times indeed!
Good times for developers
With the introduction of modular policy it is also finally possible for application developers to start bundling SELinux policy files within with their main release tar.gz downloads. By making it feasible for upstream developers to start including their application’s policy in the primary release tar.gz bundles, there is much greater incentive for developers to both learn & maintain the policy themselves, removing the policy maintainence bottleneck. In addition, it will make it possible for applications not included in Fedora Core itself – eg the thousands of apps in Fedora Extras – to start supplying policies in their own RPMs. Obviously these apps will need to take care to ensure their add-on policy doesn’t compromise the wider system policy, but the design of the modular policy ought to help prevent such problems.
These two (at first) simple sounding enhancements, should be the catalyst for SELinux to reach an even wider community of developers & remove much of the burden previously felt by adminstrators. Kudos to all the SELinux developers who worked on this step forward. I’m now off to write policy for Test-AutoBuild :-)
For the OLPC project one of the many tasks is to take a look at system optimization, and One aspect of this which frequently crops up is memory usage by mozilla based browsers. Unfortunately, as David Baron points out, getting useful analysis & bug reports has been a tricky problem. So we’ve been doing some experiments to try and get some more useful information on memory usage. At the same time this is giving us a good opportunity to do some work with the Dogtail GUI automation tool recently developed. For the first round of tests, we picked Epiphany rather than Firefox primarily because we couldn’t figure out how to make Firefox with with AT-SPI yet :-( The results have none-the-less proved interesting, suggesting there is a leak in the X server-side pixmap cache used by mozilla for storing images. When browsing without tabs, everything seems to be operating reasonably, however, after opening just a single tab, images are seemingly never released.
This certainly merits some further detailed investigation to verify whether there really is a reference counting bug, in the meanwhile read up on the techniques we’ve employeed in investigating thus far.
warning: politics below, you may wish to tune out from the rest of this post ;-)
The spring issue of Liberty‘s quarterly newsletter arrived through the mail yesterday. While the front page highlights the ongoing campaign against extraordinary rendition, there are plenty more issues of note besides this. One particularly striking article covers the increase in police powers – from January 1st 2006, the police gained the power of arrest for all criminal offences, even those not punishable by custodial sentence. The direction of the government’s thinking on matter of policing is also in evidence in the new “Police and Justice Act”, which proposes to extend police powers allowing them to:
...impose undefined and potentially limitless pre-charge bail
conditions on suspects which could include curfews and electronic
tags. Currently judges, not police, have a narrow remit to impose
post-charge bail conditions if the offender poses a flight risk,
might re-offend, or could intimidate witnesses.
This effectively gives police the powers of summary justice against suspects whom have not been charged with an offence, removing the long standing safeguard afforded by the current law requiring judicial approval / oversight.
Reading about these kind of developments in UK law & government policy tends to re-enforces my view that the our collective obsession with the actions of George Bush
in America, has led to us not paying enough attention to equally pressing matters home. This in turn has allowed the government to pass some outrageous legislation curtailing our civil liberties – what national security purpose is possibly served by prosecuting people for merely reading out names of UK servicemen killed in action.
Last friday afternoon, I quietly pushed out an update to the QEMU admin tool (being used for the OLPC SDK) which allows QEMU virtual machines to be connected up to the host network stack. Previously only a private VM-to-VM networks over IP multicast, or SLIRP-based outbound TCP only networks were working with QEMU-Admin. This new capability sets up a private network using VDE (Virtual Distributed Ethernet) switch to which QEMU VMs can connect. The dnsmasq daemon provides DNS & DHCP to this private network, allowing for zero-config networking in the QEMU guests. Finally a little VDE+IPTables magic connects the virtual network to the real host network via a TAP device. For those using NetworkManager, there is even an action script for the NetworkManager dispatcher, to automatically update the IPTables forwarding/masquerading rules when you switch between wired & wireless modes.
There’s probably still a number of bugs in this setup, but this host network bridging is the next step towards a fully automated harness for testing the OLPC ‘firmware’ images. For further info on setting up the network bridge, I’ve written a short set of instructions
