Tuesday, October 12, 2004

Twelve Step TrustABLE IT : VLSBs in VDNZs From TBAs

Twelve Step TrustABLE IT:
Virtualised Linux Standard Base (VLSB)
in Virtual Demilitarized Network Zones (VDNZ)
from Trusted Build Agents (TBA)

Back in August 11, 1998, Microsoft's Vinod Valloppillil and Josh Cohen released a memorandum titled Linux OS Competitive Analysis: The Next Java VM?, in which they predicted that Linux would become ubiquitous as a services platform. However, the title of the paper could be even more prophetic.

Consider the following.

[1] It is well known that Linux is quite portable, in fact only NETBSD comes close to the number of hardware platforms supported.

[2] What is less well known is that the Linux kernel has even been ported to run on itself, as client for a virtual Monitor platform, and even to run virtualised on other operating systems including Win2K and XP.

[3] Other operating systems, such as BSD and Sun's Solaris can also use a compatbility layer to run applications compiled for Linux directly, without the need for virtualisation.

[4]The Linux Standard Base Mission Statement is to

To develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.
[5] The above standard also defines a generic subset of the standards for each hardware platform as a source level application interface. In fact for an application to be certified for the LSB it must be tested on two of the plaforms supported by the LSB, one chosen at random by the testing body. Following the standard, it's not that difficult a job to write portable C and C++ code : Write once, compile for each platfom.

[6] The GNU Compiler Collection's future GCC 4.0 Release Series now divides the task of compiling into two stages based around Static Single Assignment trees. It should be possible to use the new GCC front ends to compile each language into a SSA tree that represents the common generic subset of the Linux Standard Base: [5].The resulting SSA tree for a build could be dumped into files, analogous to Java's JVM intermediate format, and then complied to native code for the target platform: Write once, run everywhere.

Be it open or closed source, every binary or script you execute represents a risk. It is possible to introduce hostile code at any point along the build chain, before the point where the binary is checksummed and the result digitally signed.

[7] It is possible to use constraints built into any Linux or Unix like operating system to isolate and restrict what a binary executable has access to or can do. Even without employing SELinux's manditory access controls or chroot/jail'ed environments, it is possible to run a process under a different user identity and group identity. Unix servers have used this technique for decades . With desktop applications. virtual identities and home directories can be assigned each user, the application could be limited to what files it could read and write.

[8] Because operating system security is fallible, it is sometimes better to run some services and applications on a separate computer that is isolated behind a network firewall that limits its access to the internal network and servers. This network area is sometimes called the demilitarized zone, and is often given the designated color of orange in comparison to the red colored external network and the green internal network.

[9] It is possible to use operating system virtualization in [2], to provide a virtual client operating system that access the host operating though a virutal network device. This can be used to provide a Virtual Linux Standard Base (VLSB) platform that runs in a Virtual Demilitarized Network Zone ( VDNZ).

[10] It is also possible to grant remote servers access to the Virtual Demilitarized Network Zone though the use of a Virtual Private Network (VPN). Application service providers and webservices could use this gain restricted access to an organizations servers and users desktop environment. Using VLSBs the service could be distributed over the ASPs own servers, any third party distributed hosting provider , or even the customer's ISP. Each step could increase the bandwidth and reduce the latency between the service and the customer.

[11] It is possible to bootstrap and cross compile a GCC development build chain from scratch on many platforms to mitigate even Ken Thompson's Trusting Trust issue. If you use the same open libraries and compile using GCC hosted as an LSB application, then, using the same tool chain and libraries, it is possible reproduce the build on another platform based on the same Hardware LSB standard and produce a very similar, if not identical, binary. This ability to reproduce the the build and compare binaries can provide means to audit builds to confirm that a binary is the result of compiling a particular set of source code.

[12] Governments, organizations and individuals are becoming increasingly concerned about software compatibility, conflicts and the possible existance of spyware in the software applications they use. If you have access to the source code, then you can check it and compile it for yourself. This is not an option for closed source proprietary applications, and not everyone has the resources to check each line of source code. One solution for these issues is to employ a trusted third party, separate from the application developer, who is tasked with maintaining a trusted build environment, to build the binaries from source code. The Trusted Build Agent (TBA) would hold the source to each build in escrow, releasing the source code for only open source licensed code. Competing businesses providing a TBA service in a free market would compete with each other in not only price and level of certification, but also on the ability to detect hostile, vulnerable, incompatible or just plain buggy source code. You could request a trusted build from multiple TBAs test the ability to detect defects. Defects would be reported back to the application developers, along with any patches and suggestions that provide a fix. To a lesser extent, most Linux distributions and other operating system vendors that build and redistribute open source licensed code already provide this role.

While not all of the above steps are currently available, it is the ability to combine any of the above steps which makes Linux, and to a lesser extent any operating system capable of hosting VLSBs, such a powerful platform.