IanG on Tap

Slashdot recently posted a link to some information on something called Zero Install, for something called ROX.

<digression topic="whatOnEarthIsRox">

Warning: obscure computer history rambling! Please skip to the end of this digression if you find this kind of thing tedious.

I'd never heard of ROX before I saw the link on Slashdot, although I am very familiar with its roots. It claims to be "an attempt to bring some of the good features from RISC OS to Unix and Linux". RISC OS (more info here) was the OS for a series of computers built by a British company called Acorn Computers.

Most people don't seem to have heard of Acorn today, but their legacy lives on: if you have a mobile phone, it almost certainly has a processor based on an Acorn design. These days, ARM, the company that owns the intellectual property rights for ARM processors, behaves like most three-lettered companies, and acts as though the letters don't stand for anything. The fact that it used to stand for Advanced RISC Machines is now relegated to the 'History' section of a corporate backgrounder. However, the ARM processor predates the formation of ARM the company - the CPU was in fact invented by Acorn, and in its first couple of incarnations, ARM stood for Acorn RISC Machine. So this small and now defunct British company invented one of the most popular CPUs in the world.

(The other thing Acorn are moderately well known for (particularly amongst British people over 30) is that they were the company that made the BBC Micro.)

The first versions of the ARM were made available by Acorn in one of the first 32-bit home computers, the Archimedes. (It wasn't quite the first. It was released in mid 1987. Compaq released the first ever 80386 based personal computer in 1986, but that was certainly not positioned as a home computer. Fans of a variety of 68000-based systems will also be demanding recognition at this point, but as far as I know, the 68000 family didn't get a 32-bit ALU until the 68020. The first Mac to use that processor, the Mac II, beat Acorn to it by three months, if you consider that to be a home computer. I'm not an expert on Amiga history, but I can find no record of a 68020 Amiga earlier than 1989.)

RISC OS was the operating system for the Archimedes. One of my earliest jobs was writing software for this platform. The company I worked for was Computer Concepts, who, amazingly enough, are still going, although they do PC stuff these days of course. They produced a wide variety of products, but the two main programs were Impression and Artworks, a word-processor/DTP program, and a drawing program respectively.

Incredibly enough, these programs were written in assembly language. That's right, a word processor written in ARM assembler! This was because the earliest Archimedes systems had only 512k of RAM in their entry-level configuration, so memory was extremely tight. Compiler output was just too big, and since RISC OS didn't do virtual memory (the entry level machines didn't have hard disks either) the only way you could possibly get the level of functionality these programs were trying to achieve into the space available was to write assembly language. Of course that meant they ran pretty fast too - the drawing program ran rings around contemporary versions of Corel Draw. (In fact we used to do a demo where a top-of-the-range PC would sit and draw Corel's standard 'snowbarn' demo image. It took about half a minute to redraw. Meanwhile, the exact same image would be edited in Artworks, taking something like a second to redraw in full quality mode!)

So I was pretty familiar with RISC OS, and that's why this ROX thing caught my eye. Anyway, I'll stop waxing nostalgic about old computers now...

</digression>

The idea behind this ROX Zero Install technology seems to be roughly the same as ideas such as Java Web Start, or .NET's no touch deployment, or the forthcoming ClickOnce technology. These all allow you to launch applications from the network without an explicit installation step. The idea is to make it as easy to deploy a client-side application as it is to deploy a web application: a URL should be all that's required.

What amazed me (and not in a good way) about ROX Zero Install was the 'security'. There is actually a page on this, but the main feature seems to be 'programs don't run as root so your system won't be compromised'. That's obviously necessary, but it's a long way from being sufficient! Comforting though it is that my system cannot be compromised, it's still distinctly troubling that the code runs using my user account with no additional restrictions applied. That means that it can do anything I can - if it wants to delete all my files it can. And in a single-user system (i.e., most desktop systems) this is arguably as catastrophic as trashing the system - the fact that all my system files are still intact is scant consolation if all my work has gone! OK, so it saves me from reinstalling my system, but either way I've lost all my work.

In effect, ROX Zero Install seems to run everything using what .NET calls FullTrust. FullTrust means 'able to perform any operation the user is allowed to perform'. In other words, if your code has FullTrust, the .NET Framework will not impose any additional restrictions over and above what Windows itself imposes on the user ID the code is running under. (And since I usually run as a normal user rather than a system admin, that's equivalent to not running as root; if more people adopted this practice of running with a non-privileged account, we'd see far fewer security problems on Windows systems.)

In .NET, it is a fundamental principal that code from potentially untrustworthy origins never runs with FullTrust. Java has also had a similar principal from day one - applets were always run in a secure sandbox. Compare this with the somewhat cavalier message on the home page for ROX:

"Isn't running stuff off the net a security risk?

"Isn't that where you get your software from anyway?"

So this is basically the same model that Authenticode used: let the user decide which sites they are going to trust. (Authenticode really just verifies that the code has been signed. As I understand it, ROX Zero Install does something similar - it can check GPG signatures.) But the problem with this is that it's an all or nothing approach. As with Authenticode, ROX requires that you either decide you completely trust the source of the code, or that you don't run it at all. This violates the principal of least trust - the idea that software should run with no more permissions than is necessary. By avoiding running things as root, ROX Zero Install makes a nod in that direction, but it's not nearly enough.

I'm guessing ROX's authors have already taken some flak for this, because their security page does have a section entitled "Protecting users from themselves" which describes some ways in which you might be able to work around this. One is to use another package called Subterfugue, which I gather implements a sandbox for user mode programs. However, this appears to be a dead project - in 2002, the owner of the project posted to note that it had been dormant for over a year back then, so it has presumably been inactive for around three years now. Their other suggestion is User Mode Linux - this is more or less the equivalent of running software in a Virtual PC or VMWare instance to limit the damage it can do. But these are just suggestions with, as far as I can tell, no specific instructions on how to do this in practice, much less any direct support from the system.

Still, while it doesn't have as comprehensive a security approach as either Java or .NET, it could perhaps be used to deploy applications within an organisation - it might be possible to lock down a desktop machine in a corporate environment so that it would only run code signed with a particular key. Although even then, it seems not to update by default - it appears to require the user to initiate an update explicitly. So if you're hoping to use this to push out updates in the way that .NET no-touch deployment, or the AppUpdater support, it seems like you're out of luck. There are some situations where it may be appropriate to put the user in control of when updates occur, as ROX Zero Install seems to, but it does seem to rule the technology out for scenarios where centrally-controlled updates are a requirement.

Slashdot asked if this was "The Future of Linux on the Desktop?" If it is, then I guess Linux can say goodbye to its reputation for good security...