LWN.net Logo

Getting a better Glimpse at unstable applications

August 3, 2011

This article was contributed by Nathan Willis

Developers from the Elementary OS project have crafted a new method that allows users to install and run sandboxed versions of unstable applications more safely inside their main Linux environment. Dubbed Glimpse, the system uses a chroot environment to isolate the unstable code and Another Union FS (aufs) to safely provide the chrooted binary with read access to the host filesystem. Just as importantly, Glimpse provides a straightforward mechanism for users to automatically install the unstable applications they wish to test, using pre-configured OS "profiles."

It is certainly already possible to test pre-release upstream applications before one's distribution provides them directly, of course, but the Glimpse team found the available options unsatisfying. Testing a new release in a virtual machine isolates it from real world data — which makes it difficult to get a practical feel for editing, file management, and a host of other tasks. Compiling from source deprives one of regular updates, and often introduces the time-consuming task of compiling pre-release library dependencies as well (which may also introduce instabilities to the rest of the system).

Launchpad offers an Apt-based middle ground through its personal package archives (PPAs), which quite a few development teams use to provide public testing or "daily build" repositories, but these too often require updating library packages with the resulting hit to system stability. In contrast, Glimpse provides the user with an easy-to-use launcher that can start up pre-release applications, but keeps all of the packages involved sandboxed from the host OS. The applications run at native speed, and can read local files, but cannot modify or delete them on the underlying filesystem.

Glimpse inside

The Glimpse framework makes heavy use of the Ubuntu Customization Kit (UCK) tools, which are designed to add and replace individual packages within bootable ISO images, but provide extra utilities as well — including uck-remaster-chroot-rootfs, which executes a package with chroot providing an alternate root directory.

The Glimpse workflow begins with installing a distribution "profile" package. A profile consists of Bash scripts to install, update, and purge the test OS, and scripts to install and purge specific applications. Profiles are distribution-specific, not only because they start with specific ISO releases as the base system, but also because they rely on remote Apt repositories to provide package updates, include distribution-specific tweaks to enable PulseAudio compatibility and other miscellany, and provide a custom "launcher list" of testable applications.

When run, Glimpse loads a list of the installed OS profiles. The first time a profile is used, Glimpse downloads the base ISO of the OS to be tested (in the current profiles, this is a bootable live CD image), or allows the user to locate a local copy on the filesystem (if one exists). It then uses UCK tools to "remaster" the image adding any external unstable packages users wish to test. Subsequently, Zsync pulls in any updates to the base ISO, which prevents the need to re-download the entire image if an updated alpha or beta image is released. Together, these tools handle dependency resolution in the same fashion that Apt would for a full installation.

When an installed profile is run, Glimpse opens up a second window with basic profile-control buttons: "Launch an app," "Update sandbox," "Purge file modifications," and "Remove sandbox." The "Launch an app" button opens up a window with the pre-configured launcher list defined in the profile. These launchers are merely a pre-selected list of .desktop launchers available within the sandboxed OS. Aufs is used to mount an overlay filesystem on top of specific directories (/home/$USER, /var/run, /proc, /dev/pts, /tmp, /sys, and /dev/shm). The overlay filesystem provides read-only access to the host OS underneath. That permits the user to work with his or her real files, but isolates any changes within the sandbox. When the user clicks on a launcher, the binary is executed with uck-remaster-chroot-rootfs.

Thus far, the only two profiles available are Ubuntu 11.10 and Elementary OS 0.2 (which is an Ubuntu derivative). The Elementary OS profile includes launchers for nine Elementary OS applications not found in upstream Ubuntu, such as the BeatBox audio client and Marlin file manager. A terminal is also in the list, however, which makes it possible to launch the Elementary OS version of any other application (which could be useful to test compatibility or new features).

Of course, since Elementary OS is such a new distribution — the first release was in March of 2011 — the Ubuntu 11.10 profile will certainly attract a larger set of users. Unfortunately, at the moment it is considerably less polished: it cannot initiate the application launcher window of the Elementary OS profile, and there are several bugs filed indicating that the launcher and filesystem mounting scripts are incomplete. Nevertheless, interested Ubuntu users can still make good use of the Elementary OS profile to test PPA-provided unstable packages thanks to the fact that Elementary OS 0.2 uses Ubuntu 11.10 as its base ISO, and provides a terminal in its Glimpse application launcher list.

Glimpse in practice

Glimpse itself is available as a PPA via Launchpad. The main package and the two official OS profiles are in separate packages. Zsync and UCK are dependencies, as are the GTK+ shell-script interface Zenity and a special purpose library named Gaffel that Glimpse's developers wrote in order to write better GTK dialogs for Glimpse.

Where it works, Glimpse offers a compelling user experience: there is no lag, the sandboxed applications run at full speed, and are virtually indistinguishable from natively-installed programs. The main difference is the process for launching them: the Glimpse UI must be launched first, then the proper OS profile selected, then the launcher list, then, finally, the application — with each step spawning a separate window. For launching a single application, it would be much nicer to roll those steps together (perhaps consolidating them into a sub-menu of the desktop environment's Applications menu, just to provide some level of distinction between the sandboxed and un-sandboxed applications). Then again, it could be argued that testing "unstable" code is not a process most users will engage in on a long-term, regular basis.

The Glimpse sandboxing method does have its limitations. First, no matter what distribution is used for the profile (and no matter how many libraries within the sandbox UCK loads in order to launch the app), applications running in Glimpse sandboxes are always run using the host OS's kernel. That could cause problems if the application in question needs a driver or filesystem module unavailable in the host OS kernel, but it is probably unavoidable. Second, Glimpse uses aufs to mount overlay versions of several key directories, but for one reason or another, it does not mount the /usr/share hierarchy, which has the side effect of making the host OS's window manager themes unavailable. If you use a theme not provided in the default install, your sandboxed applications will look (and perhaps even behave) differently.

Glimpse also allows only one copy of each OS profile to be installed. The profiles and their associated files (the ISO image, "remastered" update packages, and filesystem overlays) are stored in ~/.glimpse, each in its own subdirectory by distribution name, rather than by some unique key or ID, and the scripts enumerate and access them by name. While this is good enough for the general use-case (testing pre-release applications), Glimpse would be useful for some additional scenarios if multiple copies of each profile could be installed and compared.

The system also lacks a UI for adding additional application launchers and additional Apt repositories to an installed profile. Here again, for testing purposes, it is easy enough to open a terminal and run add-apt-repository to enable a third-party PPA, but as long as we are dreaming of game-changing application testing, we'd might as well dream big. Finally, as is frequently the case with new utilities, there is a shortage of documentation. The code is reasonably well-documented (and it is Bash), but I eventually gave up trying to hack the incomplete Ubuntu 11.10 profile into shape with only the Elementary OS profile for guidance.

From a security standpoint, developer Sergey Davidioff cautions that exploits breaking out of the chroot environment would then break through Glimpse as well. This could result in a privilege escalation attack, because Glimpse must be run with root privileges in order to mount aufs filesystems. The trouble is that Glimpse launches the tested applications with uck-remaster-chroot-rootfs, which was designed to execute system configuration scripts when remastering an ISO image. So although it launches the selected application in a chroot environment, it also launches that application as root. Chroot alone does not provide a security "jail." Accidental vulnerabilities are a constant threat of course, but a malicious attacker could replace a "daily build" PPA package and thus trick users into running it in Glimpse.

Glimpse of the future

Davidoff frames his introductory blog post about Glimpse as a project that will help Elementary OS users alpha-test new software for the distribution (although, for the time being, Glimpse is not yet an official sub-project of Elementary OS). There have been other tools designed to do the same task, such as Arkose and Ubuntu Test Drive. Arkose is designed to build a static sandbox around a single application, however, which means that users must repeat the process for every application they test. Ubuntu Test Drive runs the "tested" application on a remote server, and tunnels the GUI back to the client machine using the NX protocol.

Between the two, Arkose is definitely the closer match for Glimpse, and with some additional code it might be able to provide a comparable experience, with multiple applications and support for daily (or frequent) package updates. However, it would probably be shortsighted to focus solely on Glimpse's ability to track a full distribution during the alpha-testing phase. A simple scheme to run chroot-sandboxed applications with aufs-based filesystem access has other useful applications, too.

For example, I occasionally wonder whether or not some of the dust-covered binaries of long-abandoned applications in my desk drawer (such as IBM ViaVoice for Linux or The Sims) would still run — and perhaps run better on today's faster processors. To test them out, I would need to procure older, not newer, copies of a bunch of system libraries. But if I could sandbox them with Glimpse, it would be far easier to work with than running a full distribution in a virtual machine, and the odds of getting the audio to work correctly would be better as well.

If multiple profiles were supported, a range of testing scenarios become possible that today would have to be done in a virtual machine. Naturally, since Glimpse does not provide access to a sandboxed kernel, it is no replacement for a full virtual machine environment — but at the application level, it is interesting to speculate. A great many Unix graybeards will fall back on "chroot it" as the answer to how to test an untrusted program, but it has never been presented with a friendly GUI veneer on the outside. Perhaps now it has.

In the short term, Glimpse needs to complete its Ubuntu 11.10 OS profile; this will attract a significantly large user and developer base that could extend the tool further. A way to launch sandboxed application without running them as root is critical to attracting more than the casual user — although here again the exposure to attack involves planting a backdoor or exploiting a bug in an upstream application. There are bugs filed for encrypted home directory support and other features, but in the medium term the next big hurdle will be getting contributors to develop profiles for other distributions — openSUSE and Fedora are mentioned in Davidoff's blog post and, although much of the logic remains the same, supporting RPM and Yum instead of Apt and Debian packages will be a challenge, and adding support for other distribution's ISO remastering tools could be a task unto itself.

Whatever direction Glimpse takes in the future, for today it is an intriguing tool for users and developers alike. Most distributions are on six-to-eight-month release cycles, which makes it conceivable to run "unstable" applications while waiting for the next version to hit the file server. Whether testing or living on the bleeding-edge is the goal, Glimpse does make it simple to get started.


(Log in to post comments)

Getting a better Glimpse at unstable applications

Posted Aug 4, 2011 3:37 UTC (Thu) by pspinler (subscriber, #2922) [Link]

How would this compare to running something in a container (LXC) environment, with a similar aufs built container filesystem?

-- Pat

Slightly off-topic: statically linking

Posted Aug 4, 2011 8:12 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

I know it doesn't answer all of the issues addressed by Glimpse, but wouldn't it make sense to provide alpha software for testing as statically linked binaries? Then you don't have to worry about version differences, and even targeting several distributions with one binary becomes more realistic. And the security side (one or two libraries not being quite up-to-date with security fixes) is presumably less important for alpha versions - even apart from the fact that they probably need frequent rebuilds anyway.

Slightly off-topic: statically linking

Posted Aug 4, 2011 8:19 UTC (Thu) by epa (subscriber, #39769) [Link]

Isn't there a tool which takes a dynamically linked executable and a bunch of libraries, and spits out a big statically linked blob?

Slightly off-topic: statically linking

Posted Aug 4, 2011 8:24 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

> Isn't there a tool which takes a dynamically linked executable and a bunch of libraries, and spits out a big statically linked blob?

That would probably be quite a bit bigger than a properly done statically linked binary though - in theory at least; I suspect that most libraries on a typical Linux-based system are probably not at all optimised for static linking.

Slightly off-topic: statically linking

Posted Aug 5, 2011 16:48 UTC (Fri) by jsanders (subscriber, #69784) [Link]

pyinstaller does something like this for python applications, allowing you to distribute a tarball of the executable plus libraries which the user can unpack into a single directory. I use it to distribute my PyQt-based plotting application Veusz.

Binary compatibility is a myth

Posted Aug 4, 2011 9:28 UTC (Thu) by NAR (subscriber, #1313) [Link]

To test them out, I would need to procure older, not newer, copies of a bunch of system libraries.

So we can conclude that binary compatibility on Linux is a myth?

Binary compatibility is a myth ?

Posted Aug 4, 2011 10:30 UTC (Thu) by Fats (subscriber, #14882) [Link]

Yes and no, some years ago the switch of threading has caused a lot of programs to fail running without a recompile. From then on it is most of the time enough to install legacy/compatibility versions of a library to get a program running. e.g. install version .so.(n-1) of a library when version for current version of distro is .so.n

greets,
Staf.

Binary compatibility is a myth

Posted Aug 4, 2011 19:28 UTC (Thu) by iabervon (subscriber, #722) [Link]

Don't blame Linux for that-- it's all userspace's fault. And some distros actually do a remarkable job of it; I remember using Skype binaries that needed a different libc version with a different C++ ABI, and Gentoo happily pulled in the additional libraries through the package manager and it just worked. But there was definitely no way it was going to run using the same system library files that other packages were using; it wouldn't even try to, since the sonames were different.

One Laptop Per Child has similar stuff (Bitfrost/Bifrost)

Posted Aug 4, 2011 13:34 UTC (Thu) by david.a.wheeler (subscriber, #72896) [Link]

One Laptop Per Child has capabilities; look up Bitfrost/Bifrost.

One Laptop Per Child has similar stuff (Bitfrost/Bifrost)

Posted Aug 5, 2011 18:13 UTC (Fri) by bronson (subscriber, #4806) [Link]

OLPC's software stack went so far into the weeds that I'm not sure much will be salvageable.

Is it realistic to consider Bitfrost for general use?

One Laptop Per Child has similar stuff (Bitfrost/Bifrost)

Posted Apr 12, 2012 13:54 UTC (Thu) by mstone (subscriber, #58824) [Link]

The OLPC sandboxing software, "rainbow", runs fine on Debian, though it is not widely known or used. http://sandboxing.org has more details, along with links to several known alternatives.

Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds