And then a strange thing happened last week. When I launched Digikam on my laptop the UI style suddenly changed to this:

Notice in particular the different tree view expander icons and the different scrollbars. More interestingly though, the overall UI felt more responsive when interacting with Digikam. Next time I launched Digikam, it was back to the “normal” GNOME compatible theme. Wierd. And now just last night the same behaviour occurred on my other laptop – Digikam launched in a different theme, but upon restart, went back to the original theme. WTF ?

I tried playing with the ‘Themes’ menu in Digikam itself and all I can change is the colour scheme, not the widget styling. Trying  to change the KDE application theme in KDE Control Center had precisely zero effect on the Digikam theme.

Can anyone explain this behaviour ? Is there some trick to controlling KDE application themes when running under GNOME on Fedora 16 ? Most importantly how I can get back this alternative Digikam theme? I really liked how responsive it felt to interact with, compared to the standard GNOME-like theme.

• http://entangle-photo.org/download/

This release has focused almost exclusively on i18n, integrating with the Fedora Transifex team for translations

• Major code style cleanup
• Mark all translatable strings in code & UI files
• Register with Transifex for translations via Fedora team
• Pull in translations (German, Polish, Ukrainian, Japanese: full, Spanish, Chinese: partial).
• Add m4 macros for compiler warnings, missing from previous release dist.

There are a great many languages with no coverage here, so if you are able to help out, please join the Fedora translation team:

• https://fedora.transifex.net/projects/p/entangle/

In my home network, I used a LinkSys modem for the ADSL PPP login. A separate OpenWRT 54GL provides the LAN/WLAN subnet, and routes traffic to the subnet used by the LinkSys modem. While OpenWRT supports IPv6 very well, my LinkSys modem has zero support. So over the past 5 years, the LinkSys has done the IPv4 PPP login, while the aiccu tunnel daemon on my OpenWRT machine does the IPv6 tunnel login. This was never ideal, but functionally it works fine. With native IPv6 connectivity though, the PPP client is responsible for both IPv4 and IPv6 connectivity. So I faced the problem of how to enable this given, that the LinkSys ADSL modem has zero IPv6 support.

The answer to this conundrum is to move the responsibility for the PPP login off the ADSL modem entirely, by putting it into “Bridged” mode. In such a setup, the modem is solely responsible for negotiating the DSL link on the line. It then forwards all traffic from the DSL link to its LAN port, using the PPPoE (PPP-over-Ethernet) protocol. The OpenWRT box now runs the PPP daemon to establish the IP layer connectivity to the DSL ISP. This sounds complicated, but it is all surprisingly easy to configure.

• On the LinkSys router, find the DSL setup options and change the mode from “PPPoA” to “Bridged”. The loginname/password details are now irrelevant here (and indeed grayed out on my router admin page)
• On the OpenWRT router, edit the /etc/config/network section and add PPPoE config section, taking care to add the ‘ipv6=1′ option. Contrary to instructions from my ISP, I didn’t need to configure any IPv6 address/subnet on the ppp0 interface, it is automatically handled via link-local addresses.

  config 'interface' 'wan'
  	option 'ifname' 'eth0.1'
  	option 'proto' 'pppoe'
  	option 'username' 'NNNNNNN@adsllogin.co.uk'
  	option 'password' 'XXXXXXX'
  	option 'defaultroute' '1'
  	option 'peerdns' '1'
  	option 'ipv6' '1'

• Restart networking on the OpenWRT box (/etc/init.d/network restart). If all went to plan the OpenWRT box now has a login to the DSL ISP with both IPv4 and IPv6 connectivity

  ppp0      Link encap:Point-to-Point Protocol
            inet addr:XX.YY.ZZ.AA  P-t-P:BB.CC.DD.EE  Mask:255.255.255.255
            inet6 addr: fe80::XXXX:YYYY::ZZZZ/10 Scope:Link
            UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
            RX packets:169629 errors:0 dropped:0 overruns:0 frame:0
            TX packets:120721 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:3
            RX bytes:228671985 (218.0 MiB)  TX bytes:11603336 (11.0 MiB)

• Provide IPv6 connectivity to the LAN using RADVD. With OpenWRT this is trivially achieved by editing /etc/config/radvd. UKFSN/Enta provided me with a /56 subnet for local LAN use. I just allocated the first /64 of this to my LAN for now. The rest I will for creating various subnets between virtual machines I test with

  config prefix
  	option interface	'lan'
  	option prefix           '2001:XXXX:YYYY:ZZZZ::/64'
  	option AdvOnLink	1
  	option AdvAutonomous	1
  	option AdvRouterAddr	0
  	option ignore		0

• Don’t forget to ensure that a firewall is up for the IPv6 link – there’s no NAT to “protect” you, so you want to setup a “deny all” rule for incoming connectivity on the “ppp0″ device.

The upshot is that 5 years on from my initial setup, I now have native IPv6 connectivity everywhere. No more IPv6-in-IPv4 tunnels required. I’ve not compared the download speeds of my native IPv6 connection against the Sixxs IPv6 tunnel I used previously, but I can say that the ping times have improved. Previously IPv6 pings were about 10ms slower than IPv4 pings. Now the ping times are identical, which is nice :-)

1. Get the initial Nova GIT checkout

   $ mkdir $HOME/src/cloud
   $ cd $HOME/src/cloud
   $ git clone git://github.com/openstack/nova.git
   $ cd nova

2. Install some basic pre-reqs, and ensure python-distutils-extra is not present since that conflicts with part of the openstack build system

   $ sudo yum install gcc python-pep8 python-virtualenv m2crypto libvirt libvirt-python libxslt-devel libxml2-devel
   $ sudo yum remove python-distutils-extra

3. Visit the OpenStack Gerrit Website, and follow ‘Sign In’ link which redirects to LaunchPad for authentication
4. Back on Gerrit site, now signed in, follow ‘Settings’ link, select ‘SSH Public Keys’ page, and paste your SSH public key (eg contents of $HOME/.ssh/id_rsa.pub)
5. Test SSH connectivity from the CLI

   $ ssh -p 29418 berrange@review.openstack.org
   The authenticity of host '[review.openstack.org]:29418 ([173.203.103.119]:29418)' can't be established.
   RSA key fingerprint is ee:2f:ac:1b:f8:25:d0:39:be:55:02:c7:76:5e:39:53.
   Are you sure you want to continue connecting (yes/no)? yes
   Warning: Permanently added '[review.openstack.org]:29418,[173.203.103.119]:29418' (RSA) to the list of known hosts.
   
   **** Welcome to Gerrit Code Review ****
   
   Hi Daniel Berrange, you have successfully connected over SSH.
   
   Unfortunately, interactive shells are disabled.
   To clone a hosted Git repository, use:
   
   git clone ssh://berrange@review.openstack.org:29418/REPOSITORY_NAME.git
   
   Connection to review.openstack.org closed.

6. Install commit hook to ensure ‘ChangeId’ fields get added to your commits

   $ scp -p -P 29418 berrange@review.openstack.org:hooks/commit-msg .git/hooks/

7. Add the gerrit remote to GIT config

   $ git remote add gerrit ssh://berrange@review.openstack.org:29418/openstack/nova.git

8. Start a new branch for your work

   $ git checkout -b venv-install-fixes

9. Make whatever code changes you need todo

   $ vi tools/virtual_venv.py
   $ git add -u
   
   (Don't forget to add yourself to Authors if this is your first change)

10. Commit the changes, checking the commit message gets a ‘Change-Id’ line added just prior to the signed-off-by line

    $ git commit -s
    $ git show
    commit fd682a28fb4591c65f20129d4bfb4eccf1232cb8
    Author: Daniel P. Berrange <berrange@redhat.com>
    Date: Thu Jan 5 13:15:15 2012 +0000
    
    Tell users what is about to be installed via sudo
    
    Rather than just giving users the sudo password prompt immediately,
    actually tell them what is about to be installed, so they know what
    privileged action is being attempted.
    
    Change-Id: Ic0c1de812be119384753895531a008075b13494e
    Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

    If the commit is fixing a OpenStack bug, then the commit message should include a line “BugXXXX” where XXXX is the bug number. Gerrit uses this to link to the bug tracker

11. Run the unit test suite, and the python pep8 syntax test suite; Be prepared to wait a long time

    $ ./run_tests.sh
    $ ./run_tests.sh --pep8

12. Send the changes to Gerrit for review

    $ git push gerrit HEAD:refs/for/master

13. Wait for email notifications of review, or watch the OpenStack Gerrit Website.
14. If problems are found by reviewers, or the automated smoke stack tests. Repeat steps 9->l;12, but use ‘git commit –amend’ to ensure you preserve the original “Change-Id” line in the commit message. This lets gerrit track followup patches.
15. If everything passes review & testing, it will be automatically merged into master.

There is also a GIT plugin  “git review” available in the git-review RPM, which can provide syntactic sugar for step 12, but personally I don’t find it adds significant value to be worth my while using.

I can see the attraction of Gerrit, but I personally still prefer the practice of using git send-email for reviewing on mailing lists. My problems with Gerrit are

• The email notifications sent out for new patches are almost worse than useless as an information source
• While very pretty, the web UI for browsing the diffs is really quite cumbersome to use
• Poor support for reviewing large patch series
• Use of merge commits makes navigating GIT history cumbersome, forcing the use of the graphical gitk viewer tool

• Fix crash in handling camera control combo list
• Add notice about need to set XDG_DATA_DIRS when installing into unusual directories
• Add workaround to avoid immediate crash if schemas were not found in XDG_DATA_DIRS
• Compile schema files after installation
• Fix crash updating widget sensitivity
• Fix crashes & race conditions during capture of images
• Fix infinite preview error message popups which can hang the window manager
• Fix crash when retrying a failed connection attempt
• Fix thread locking when hiding status display
• Avoid running multiple threads for monitoring status
• Fix initial sensitivity of camera control panels
• Update README with new URLs for bugs/mailing lists

Since the latest release I have also registered Entangle with GNA!, to get support for mailing lists and bug tracking.

pius (PGP Individual UID Signer) helps attendees of PGP keysigning parties. It is the main utility and allows you to quickly and easily sign each UID on a set of PGP keys. It is designed to take the pain out of the sign-all-the-keys part of PGP Keysigning Party while adding security to the process.

…

That can already be time consuming, but preferrably, you want to verify the identity in each UID, which means verifying the email addresses. There are a few ways to do this, but one of them is to sign each UID on the key individually (which requires import-sign-export-delete for each UID), encrypt-emailing that key to the email address in the UID. This can be incredibly time consuming.

That’s where pius comes in. Pius will do all the work for you – all you have to do is confirm the fingerprint for each key. It will then take care of signing each UID cleanly, minimizing the key, and using PGP/Mime email to send it, encrypted, to the email address in the UID.

The steps Jim defined for us to follow using Pius were as follows

1. Collate a list of everyone’s key IDs. Our list looked like this (cut down to save space)

    # cat > keyids.txt <<EOF
    4096R/000BEEEE 2010-06-14 Jim Meyering
    4096R/E1B768A0 2011-10-11 Richard W.M. Jones
    4096R/15104FDF 2011-10-11 Daniel P. Berrange
    ...
    EOF

2. Download all the keys from a key server (it is assumed everyone has already uploaded their own key to a server)

    # id_list=$(perl -nle 'm!^\d{4}R/(\S{8}) ! and print $1' keyids.txt)
    # gpg --recv-keys  $(echo $id_list)

3. Generate a list of fingerprints for all keys that are to be signed

    # gpg --fingerprint $(echo $id_list)

4. Verify all the fingerprints and their owners’ identities.
   This is the security critical part. You generally want to meet the person face-to-face, verify their identity via some trusted means (passport, driving license, etc). They should read their key fingerprint out to you, and you should verify that it matches the fingerprint of that downloaded from the key server.
5. Use Pius to sign all the keys whose fingerprints were verified.

   MAIL_HOST=smtp.your.mail.server.com
   me=your@email.address.com   (eg dan@berrange.com)
   my_id=XXXXXXXXXXX  (Your GPG Key ID eg  15104FDF)
   # pius --mail-host=MAIL_HOST --no-pgp-mime --mail=$me --signer=$my_id $(echo $id_list)

What Pius does here is that for each key ID it is given, it will sign each individual identity (email address). The signature will be ascii-armoured and then sent to the email address associated with that identity. If a user has multiple email addresses on their key, they will receive one signature email per address. The email contains instructions for what the receipient should do. The email will look something like this

From: eblake@redhat.com
To: berrange@redhat.com
Subject: Your signed PGP key

[-- Attachment #1 --]
[-- Type: text/plain, Encoding: 7bit, Size: 0.7K --]

Hello,

Attached is a copy of your PGP key (0x15104fdf) signed by my key
(0xa7a16b4a2527436a).

If your key has more than one UID, than this key only has the UID associated
with this email address (berrange@redhat.com) signed and you will receive
additional emails containing signatures of the other UIDs at the respective
email addresses.

Please take the attached message and decrypt it and then import it.
Something like this should work:

   gpg -d  | gpg --import

Then, don't forget to send it to a keyserver:

   gpg --keyserver pool.sks-keyservers.net --send-key 15104fdf

If you have any questions, let me know.

Generated by PIUS (http://www.phildev.net/pius/).

[-- Attachment #2: 15104fdf__berrange_at_redhat.com_ENCRYPTED.asc --]
[-- Type: application/octet-stream, Encoding: 7bit, Size: 4.6K --]

The final thing, once everyone has dealt with the emails they received, is to refresh your local key database to pull down all the new signatures

# gpg --recv-keys  $(echo $id_list)

I should point out that Pius isn’t just for mass key signing parties. Even if you only have 1 single key you want to sign, it is still a very convenient tool to use. The simplified set of steps to go through would be

# gpg --recv-key XXXXXXXX
# gpg --fingerprint XXXXXXXX
# ...verify person's identity & fingerprint
# pius --mail-host=MAIL_HOST --no-pgp-mime --mail=$me --signer=$my_id XXXXXXX
# ....some time later...
# gpg --recv-key XXXXXXXX

Thanks again to Jim Meyering for pointing out Pius and doing the organization for our key signing party & defining the steps I describe above. BTW, Pius is available in Fedora from F16 onwards.

Besides these virtualization related speakers, there are a great many other Red Hat people attending FOSDEM this year, so we put together a small flyer highlighting all their talks. In keeping with the spirit of FOSDEM, these talks will of course be community / technically focused, not corporate marketing ware :-) I look forward to meeting many people at FOSDEM this year, and if all goes well, make it a regular conference to attend.

• Axiom #1: Your password(s) will be compromised. There is no “if”, only “when”

It follows from this, that it is the epitome of foolishness to use the same password for more than one site. Even if you are diligent to watch for news reports of site compromises & quickly change your passwords across all other sites, you are wasting hours of time, and still vulnerable for the period between the attack taking place & being reported in the media (if at all). Out of curiosity, I made a list of every website I could remember where I had registered an account of some kind. I was worried when the list got to 50, I was shocked when it went over 100, and I stopped counting thereafter.

There is a barrage of often conflicting suggestions about how to create strong passwords for accounts. Most websites simply say things like “you must use a mixture of at least 8 letters, numbers and special symbols“. Google have been trying to educate people about how to make up more easily remembered passwords, but XKCD points out the flaws in these commonly suggested approaches. Even if you do decide upon some nice scheme for creating your passwords, you quickly come across many websites which will reject your carefully thought up & remembered password. Compound this with the fact that many websites (typically financial ones) also require you to enter “passwords hints” based on questions that are supposedly easy to remember, but in fact turn out to be anything but. Now multiply by the number of sites you need passwords for (x100). This leads me inescapably to my second axiom of password management:

• Axiom #2: It is beyond the capabilities of the human brain to remember enough strong passwords

There have been a great many proposals for shared authentication services, whether owned & managed centrally by a corporation like Microsoft Passport, or completely decentralized & vendor independent like OpenID. Today out of all the 100+ sites I use, I can count the number that allow OpenID login on the fingers of one hand. More recently the big social networks have been having some success with positioning themselves as the managers of your identity & providers of authentication to other sites. I am not happy with the idea of any social network being the controller of not only my online identity, but also controller of access to every single website I register with. I don’t trust them with all this data, and they are an extremely high value target for any would be attackers if they control all your website logins. Letting them control all my logins, feels akin to just re-using the same password across every website. I know they have marginally stronger login procedures than most sites, by allowing you to authenticate individual clients used to login, but this isn’t enough to balance the downside. In fact I’m not really convinced that I want any online service to be the manager or all my login details for websites. It is just too big a single point of trust/failure.

A minority of online banking websites now provide you some form of hardware key token generator, or pin entry device to authenticate with. This is clearly not going to work for most websites, due to the cost & distribution problem. Even within the limited scope of financial websites the practicality is limited – if every financial institution I dealt with had key token generators, I’d have a huge pile of hardware devices to look after ! I do like hardware authentication devices and now use them for login to any personal SSH servers that I manage, but with a few exceptions like Fedora, they are not a solution for the online password problem today or the forseable future. I am depressingly lead to my third axiom of password management:

• Axiom #3: Widespread password authentication is here to stay for many, many years to come

Hmm, perhaps the problem is better described by mapping to the 5 stages of grief

1. Denial – only careless people have their details compromised, i’ll be fine using the same 4-5 passwords across all sites
2. Anger – how could $WEBSITE have been so badly run / protected, to let themselves be compromised
3. Bargaining – if I just let Facebook handle all my logins, they’ll solve all the hard problems for me
4. Depression – the industry will never get its act together & solve authentication
5. Acceptance – passwords are here to stay, what can I do to minimize my risks

Well I think I am at step 5 now. I have accepted that passwords are here to stay, that sooner or later one or more of the sites I am registered with will be compromised, and it is impossible for me to remember enough passwords. My goal is thus to minimise the pain and damage.

My conclusion is that the only viable way to manage passwords today is to do the one thing everyone tells you never to do

• Write down all the passwords

Of course this shouldn’t be taken too literally. I am not suggesting to put a post-it on the monitor with the passwords on it, rather I mean store the passwords in some secure location, which is in turn protected a master password. ie use a password manager application.

Using KeePassX for managing passwords

After looking at a few options on Linux, I ended up choosing KeePassX as my password manager because it had a quite advanced set of features that appealed to me. Before anyone comments, I had discounted any usage of a password manager built into the web browser before even starting. The browser is a directly network facing process of great complexity and frequent security flaws – they just aren’t the right place to be storing all your valuable secrets. The features in KeepPassX that I liked were:

• Passwords are stored encrypted in a structured database
• It is possible to specify many different metadata attributes with each password, username, site URL, title, comment, and more.
• It can copy the password to the clipboard, allowing paste into web browser forms, avoiding the need to manually type in long password sequences
• It automatically purges passwords from the clipboard after 30 seconds to minimise the window when it is visible
• The database can be set to automatically lock itself against after 30 seconds, requiring the master password to be entered again to access further password entries
• The password database can be secured using a password, or a keyfile, or both. The keyfile is just a plain file with random bytes stored somewhere (like a USB key)
• An advanced password generator with many tunable options

I have several laptops and I want the password database to be usable from either machine. At the same time though, the password database should not become a single point of failure / data loss, so there needs to be multiple copies of it.  Using a password database does have the downside that it becomes a nice single point of attack for the bad guys. It would thus be desirable to have separate password databases for websites used on a general day-to-day business vs security critical seldom used sites ie bank accounts, and other financial institutions. With this in mind the way I decided to use KeepPassX is as follows

• I purchased 4x USB stick 4 GB capacity for < 5 GBP each, two coloured black and two coloured white
• All 4 USB sticks were split into 2 partitions, each of 2 GB size.
• The primary partition is formatted with a Fedora 16 LiveCD. This is to facilitate easy access to the passwords, should I find myself without one of my own Linux laptops close by
• The second partition is setup with LUKS full disk encryption and formatted with ext4.
• The partition with the encrypted filesystem is used to store the KeePassX database files and any other important files (GPG keys, SSH keys, etc)
• The black coloured USB sticks are used to store a database for financial account details
• The white coloured USB sticks are used to store a database for any other website logins
• One USB stick of each colour is the designated backup. The backup sticks are kept in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’
• A shell script which will synchronize files between sticks, to be run periodically to ensure recent-ish backups

With that all decided there merely followed the tedious task of logging into over 100 websites and changing my password on each one. I decided that my default policy would be to let KeePassX generate a new random password for each site made up of letters, numbers and special characters, with a length of 20 characters. Surprisingly the vast majority of sites coped just fine with these passwords. BugZilla turns out to be limited to 16 characters and a handful of ecommerce sites had even shorter limits, or refused to allow use of special characters!

Using E-Mail “plus addressing” for accounts

It is often said that when bad guys have compromised a website’s account database they will try to reuse the same email and password on a number of other high value sites. Since many people reuse passwords & many sites allow login based off an email address, the bad guys will trivially gain access to a significant number of accounts on other non-compromised sites. I am already generating unique passwords for each site, but to add just one more roadblock, I decided that while changing passwords, I would also set a unique email address for every single site.

My exim mail server supports what is known as “plus addressing”, whereby you can append an arbitrary tag to the local part of an email address. For example given an address “fred@example.com” you have an infinite number of unique email address “fred+TAG@example.com” where “TAG” is any reasonable string. Sadly when I tried using plus addressing, I immediately hit problems, because many (broken) form data validation checks think “+” is not a valid character to use in email addresses, or worse they would accept the address but all email they sent would end up in a black hole. Fortunately, it is a trivial matter to reconfigure Exim to allow use of ‘-’ as the separator for plus addressing, ie to allow “fred-TAG@example.com“.

Out of > 100 websites I updated my account details on, only 1 rejected the use of ‘-’ in my email address. So now more or less every account I am registered to has both a unique password and unique email address.

In the end, the main thing I an unhappy about is that using a password manager presents a single point of attack for a local computer virus/trojan. Given the frequency with which websites are being compromised these days & the number of sites I need to remember passwords for, I think overall this is clearly still a net win. I will remain on the lookout though for ways to improve the security of the password manager database itself.

Background motivation & prototype

For a few Fedora releases, users have had the SELinux sandbox command which will execute a command with a strictly confined SELinux context applied. It is also able to make limited use of the kernel filesystem namespace feature, to allow changes to the mount table inside the sandbox. For example, the common case is to put in place a different $HOME. The SELinux sandbox has been quite effective, but there is a limit to what can be done with SELinux policy alone, as evidenced by the need to create a setuid helper to enable use of the kernel namespace feature. Architecturally this gets even more problematic as new feature requests need to be dealt with.

As most readers are no doubt aware, libvirt provides a virtualization management API, with support for a wide variety of virtualization technologies. The KVM driver is easily the most advanced and actively developed driver for libvirt with a very wide array of features for machine based virtualization. In terms of container based virtualization, the LXC driver is the most advanced driver in libvirt, often getting new features “for free” since it shares alot of code with the KVM driver, in particular anything cgroup based. The LXC driver has always had the ability to pass arbitrary host filesystems through to the container, and the KVM driver gained similar capabilities last year with the inclusion of support for virtio 9p filesystems. One of the well known security features in libvirt is sVirt, which leverages MAC technology like SELinux to strictly confine the execution environment of QEMU. This has also now been adapted to work for the LXC driver.

Looking at the architecture of the SELinux sandbox command last year, it occurred to me that the core concepts mapped very well to the host filesystem passthrough & sVirt features in libvirt’s KVM & LXC drivers. In other words, it ought to be possible to create application sandboxes using the libvirt API and suitably advanced drivers like KVM or LXC. A few weeks hacking resulted in a proof of concept tool virt-sandbox which can run simple commands in sandboxes built on LXC or KVM.

The libvirt-sandbox API

A command line tool for running applications inside a sandbox is great, but even more useful would be an API for creating application sandboxes that programmers can use directly. While libvirt provides an API that is portable across different virtualization technologies, it cannot magically hide the differences in feature set or architecture between the technologies. Thus the decision was taken to create a new library called libvirt-sandbox that provides a higher level API for managing application sandboxes, built on top of libvirt. The virt-sandbox command from the proof of concept would then be re-implemented using this library API.

The libvirt-sandbox library is built using GObject to enable it to be accessible to any programming language via GObject Introspection. The basic idea is that programmer simply defines the desired characteristics of the sandbox, such as the command to be executed, any arguments, filesystems to be exposed from host, any bind mounts, private networking configuration, etc. From this configuration description, libvirt-sandbox will decide upon & construct a libvirt guest XML configuration that can actually provided the requested characteristics. In other words, the libvirt-sandbox API is providing a layer of policy avoid libvirt, to isolate the application developer from the implementation details of the underlying hypervisor.

Building sandboxes using LXC is quite straightforward, since application confinement is a core competency of LXC. Thus I will move straight to the KVM implementation, which is where the real fun is. Booting up an entire virtual machine probably sounds like quite a slow process, but it really need not be particularly if you have a well constrained hardware definition which avoids any need for probing. People also generally assume that running a KVM guest, means having a guest operating system install. This is absolutely something that is not acceptable for application sandboxing, and indeed not actually necessary. In a nutshell, libvirt-sandbox creates a new initrd image containing a custom init binary. This init binary simply loads the virtio-9p kernel module and then mounts the host OS’ root filesystem as the guest’s root filesystem, readonly of course. It then hands off to a second boot strap process which runs the desired application binary and forwards I/O back to the host OS, until the sandboxed application exits. Finally the init process powers off the virtual machine. To get an idea of the overhead, the /bin/false binary can be executed inside a KVM sandbox with an overall execution time of 4 seconds. That is the total time for libvirt to start QEMU, QEMU to run its BIOS, the BIOS to load the kernel + initrd, the kenrel to boot up, /bin/false to run, and the kernel to shutdown & QEMU to exit. I think 3 seconds is pretty impressive todo all that. This is a constant overhead, so for a long running command like an MP3 encoder, it disappears into the background noise. With sufficient optimization, I’m fairly sure we could get the overhead down to approx 2 seconds.

Using the virt-sandbox command

The Fedora review of the libvirt-sandbox package was nice & straightforward, so the package is already available in rawhide for ready to test the VirtSandbox F17 feature. The virt-sandbox command is provided by the libvirt-sandbox RPM package

# yum install libvirt-sandbox

Assuming libvirt is already installed & able to run either LXC or KVM guests, everything is ready to use immediately.

A first example is to run the ‘/bin/date’ command inside a KVM sandbox:

$ virt-sandbox -c qemu:///session  /bin/date
Thu Jan 12 22:30:03 GMT 2012

You want proof that this really is running an entire KVM guest ? How about looking at the /proc/cpuinfo contents:

$ virt-sandbox -c qemu:///session /bin/cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 2
model name	: QEMU Virtual CPU version 1.0
stepping	: 3
cpu MHz		: 2793.084
cache size	: 4096 KB
fpu		: yes
fpu_exception	: yes
cpuid level	: 4
wp		: yes
flags		: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm up rep_good nopl pni cx16 hypervisor lahf_lm
bogomips	: 5586.16
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:

How about using LXC instead of KVM, and providing an interactive console instead of just a one-shot command ? Yes, we can do that too:

$ virt-sandbox -c lxc:/// /bin/sh
sh-4.2$ ps -axuwf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0 165436  3756 pts/0    Ss+  22:31   0:00 libvirt-sandbox-init-lxc
berrange    24  0.0  0.1 167680  4688 pts/0    S+   22:31   0:00 libvirt-sandbox-init-common
berrange    47  0.0  0.0  13852  1608 pts/1    Ss   22:31   0:00  \_ /bin/sh
berrange    48  0.0  0.0  13124   996 pts/1    R+   22:31   0:00      \_ ps -axuwf

Notice how we only see the processes from our sandbox, none from the host OS. There are many more examples I’d like to illustrate, but this post is already far too long.

Future development

This blog post might give the impression that every is complete & operational, but that is far from the truth. This is only the bare minimum functionality to enable some real world usage.  Things that are yet to be dealt with include

• Write suitable SELinux policy extensions to allow KVM to access host OS filesystems in readonly mode. Currently you need to run in permissive mode which is obviously something that needs solving before F17
• Turn the virt-viewer command code for SPICE/VNC into a formal API and use that to provide a graphical sandbox running Xorg.
• Integrate a tool that is able to automatically create sandbox instances for system services like apache to facilitate confined vhosting deployments
• Correctly propagate exit status from the sandboxed command to the host OS
• Unentangle stderr and stdout from the sandboxed command
• Figure out how to make dhclient work nicely when / is readonly and resolv.conf must be updated in-place
• Expose all the libvirt performance tuning controls to allow disk / net I/O controls, CPU scheduling, NUMA affinity, etc
• Wire up libvirt’s firewall capability to allow detailed filtering of network traffic to/from sandboxes
• Much more…

For those attending FOSDEM this year, I will be giving a presentation about libvirt-sandbox in the virt/cloud track.

Oh and as well as the released tar.gz mentioned in the first paragraph, or the Fedora RPM, the  code is all available in GIT