diff options
| author | Alyssa Ross <hi@alyssa.is> | 2019-08-18 00:01:38 +0000 |
|---|---|---|
| committer | Alyssa Ross <hi@alyssa.is> | 2019-08-18 00:01:38 +0000 |
| commit | 683d0f7761e68e130590adce9b40cbbd59f92b6d (patch) | |
| tree | a11ab0f523b3cccbfa80d03c45b5fe510a90cf18 | |
| download | www-683d0f7761e68e130590adce9b40cbbd59f92b6d.tar www-683d0f7761e68e130590adce9b40cbbd59f92b6d.tar.gz www-683d0f7761e68e130590adce9b40cbbd59f92b6d.tar.bz2 www-683d0f7761e68e130590adce9b40cbbd59f92b6d.tar.lz www-683d0f7761e68e130590adce9b40cbbd59f92b6d.tar.xz www-683d0f7761e68e130590adce9b40cbbd59f92b6d.tar.zst www-683d0f7761e68e130590adce9b40cbbd59f92b6d.zip | |
Initial commit
| -rw-r--r-- | index.html | 289 | ||||
| -rw-r--r-- | nlnet-pet-2019-03.html | 423 |
2 files changed, 712 insertions, 0 deletions
diff --git a/index.html b/index.html new file mode 100644 index 0000000..dd596dc --- /dev/null +++ b/index.html @@ -0,0 +1,289 @@ +<!doctype html> +<html lang="en"> + +<head> + +<meta charset="utf-8"> +<meta name="viewport" content="width=device-width,initial-scale=1"> + +<title>Spectrum, a step towards usable secure computing</title> + +<body> + +<h1>Spectrum — a step towards <em>usable</em> secure computing</h1> + +<p> +<a href="mailto:hi@alyssa.is">Alyssa Ross</a>, 2018-2019. + +<p> +You may distribute this work under the terms of either +the <a href="https://creativecommons.org/licenses/by-sa/4.0/">CC-BY-SA</a> +license (version 4.0 or later), or +the <a href="https://www.gnu.org/licenses/gfdl.html">GNU Free +Documentation License</a> (version 1.2 or later), at your option. + +<h2>Motivation</h2> + +<p> +Existing attempts to improve on the security of Unix-like operating +systems for everyday personal use have been hampered by complexity, +bugs, and security theatre. The concept of isolating applications by +giving them what appears to be a dedicated computer to run in is a +solid one, because it allows virtually all existing software to run +without modification. However, allowing all these isolated computers +to persist state leads to large maintenance costs — you now +have <var>n</var> stateful computers to maintain, not one. + +<p> +By minimizing the persistent state these computers are allowed to +store to a well-defined absolute minimum required by the software +running inside them, not only do we improve maintainability by +minimising side effects and even allowing the computers to be +regenerated without data loss if required, we also massively reduce +the avenues to persisting malware. + +<p> +Mutable state across the whole system isolated into two locations on +the host: a global state store, which is broken down by application +instance, and a global configuration file defining all configuration +for the host, and the isolated environments for each application +instance. Aside from these two locations, the host computer should +prevent persistent state as much as possible. This means that it is +possible to restore the host computer, along with all the isolated +application environments, simply by restoring a copy of the global +state store and configuration file. After an audit of the global +configuration, a potentially compromised host could be safely restored +onto a new computer without risk of the new host inheriting the +infection from the old one, since the only mutable data affecting the +host is the global configuration file. (Of course, this does not +prevent the new host from being compromised shortly afterward through +the same methods.) + +<h3>Existing implementations of security by compartmentalization</h3> + +<h4>Qubes OS</h4> + +<p> +Qubes OS is a distribution of the Xen hypervisor that isolates IO and +user applications inside their own dedicated virtual machines. Many +people interested in secure computing are aware of Qubes, however they +are often hampered by usability issues: + +<ul> + + <li> + Hardware compatibility is extremely limited. People often have + to buy a new computer just to use Qubes, and even then it can be a + struggle to set up. + + <li> + People are reluctant to use Xen on their computer for power + management etc. reasons. + + <li> + VMs are heavy, and there is no isolation between applications in the + same domain (VM). + + <li> + GUI applications are buggy, command line tools are mostly + undocumented. + + <li> + Maintaining many different TemplateVMs with persistent state is + difficult. (Qubes can use Salt to mitigate this.) + +</ul> + +<p> +However, the Qubes developers have created utilities for using +compartmentalized environments that could be very useful to other +implementations. For example, Qubes allows clipboard data to be safely +shared between isolated environments with explicit user action on both +ends, and Qubes Split GPG allows one environment to perform operations +using a GPG key stored in another environment, with permission granted +on a per-operation basis. + +<h4>Subgraph OS</h4> + +<p> +Subgraph only provides isolation to the 22 applications they have +manually containerized. Any other software is still run as normal. We +consider this a major security issue. + +<p> +The last release of SubgraphOS was an alpha in 2017. + +<h2>Implementation</h2> + +<p> +Because of the explosion of interest in compartmentalized computing in +recent years, there exists a plethora of existing work that can be +harnessed to implement these concepts. + +<h3>Containers</h3> + +<p> +A container is an isolated computing environment created using a +variety of features of the Linux kernel. A container can +be <em>almost</em> entirely isolated from the host system, and those +components that <em>are</em> shared can likely be made inaccessible to +isolated applications by denying them root access to their isolated +environments. Unlike virtual machines, containers share a kernel with +the host operating system, and do not require specially allocated +resources (although it is still possible to limit resource use by a +container). This makes containers able to deliver good performance +with far looser hardware requirements than virtual machines. + +<p> +In the proof of concept implementation, Docker, a popular +implementation of containers, is used. However, there is probably +not any tight coupling to Docker-specific features, and so Docker +could most likely be easily swapped out for another container +implementation, or even for virtual machines. + +<h4>Containers for personal computing</h4> + +<p> +Containers have mostly been designed for isolating headless server +applications. Additional challenges present themselves when applying +container-based application isolation to personal computing. + +<h5>Graphical User Interfaces</h5> + +<p> +The X11 protocol provides no isolation between applications +whatsoever. Any application (including one running on a remote server +using SSH X forwarding) can capture windows of other applications, +read from them, and even send events to them freely. The solution to +this problem is to use a separate X server for each container, and +then forward them over another protocol (such as VNC) to the window +manager running either on the host or, preferably, in a dedicated +container of its own. The pre-existing Xpra software provides this +capability. Doing this inevitably gives rise to yet more problems, +mostly around performance, although these should be solvable also: + +<ul> + + <li> + The current implementation of Xpra window forwarding causes + noticeable lag in high frame rate operations such as video playback + or gradual window resizing. This implementation uses a Unix socket + inside a tmpfs on the host, which is then mounted into the + container. However, Xpra also supports communicating over mapped + memory, and this should be significantly faster. + + <li> + An Xpra server (of which there must be one for every isolated + application instance) takes most of a minute to start. This + means that the delay before a window appears is extremely long + compared to traditional personal computing systems. One promising + solution to this takes advantage of the fact that Xpra servers do + not require any application specific configuration (at least for + most applications), and so while each application instance requires + its own Xpra server, the server does not need to have been created + specifically for this application. This allows us to create several + Xpra servers ahead of time (in containers of themselves), and then + assign them to application instances on demand, starting the process + of generating the next Xpra server in the background. + +</ul> + +<p> +Given the fundamental shortcomings in X, it might seem obvious to use +Wayland instead. Unlike X, Wayland was designed with security and +isolation between applications in mind. However, existing Wayland +implementations have no way of controlling isolation between +applications. A single Wayland compositor could provide e.g. clipboard +isolation in a similar way to Qubes or Xpra, but this doesn't exist +yet. Writing a Wayland compositor is not a simple task, even with a +library like wlroots that does a lot of heavy lifting, and it would +also couple a user to a single window manager or desktop +environment. While Wayland is extremely usable for general-purpose +desktop computing at this point, until a solution for these issues is +reached, Wayland is not suitable for a compartmentalized operating +system. + +<h3>NixOS</h3> + +<p> +The proof of concept implementation is built on top of NixOS Linux, an +operating system which is itself built on Nix, a purely functional +package manager. Nix provides pure packages (meaning packages will be +built from identical inputs each time — their outputs will not +necessarily be byte-identical). NixOS makes it possible to define an +entire GNU/Linux system in this manner. + +<p> +However, NixOS does not attempt to completely eliminate undeclared +state — it even allows for imperative package installation, which +makes a Nix package that has not been defined in the global +configuration available in the current environment. Responsibility for +eliminating this sort of mutable state lies with the Spectrum +implementation. + +<p> +The nixpkgs repository provides functions for generating Docker +containers from Nix expressions, using existing Nix package +definitions. These containers are not full NixOS installations — in +fact, they don't even have Nix or coreutils installed by default. This +ensures only the minimum software required for the isolated +application to run is available, reducing attack surface. + +<p> +NixOS provides its own container implementation, based on +systemd-nspawn however this is not suitable for security by +compartmentalization. Firstly, it is designed to contain full +installations of NixOS, rather than single applications. Further, it +has apparently proven to be unreliable and suffer breakages, and its +focus is not on providing truly isolated computing environments. By +contrast, other container implementations (such as, but not +exclusively, Docker), have reached a point of relative stability, and +had extensive resources put into making them as isolated as possible +from the host system. + +<h2>Current status</h2> + +<p> +Getting Spectrum to the point it needs to be for other people to be +able to use it is a large undertaking, that requires my full +attention. To this end, I am currently actively seeking funding to +work on Spectrum full time. Once this is completed, I can begin work +on Spectrum in earnest. Source code repositories and discussion +channels will be made available immediately, and I will publish +regular status updates. As soon as funding is sorted out (and I am +confident it will be), I want it to be as clear as possible that +Spectrum is not vapourware, and that progress is rapidly being made. + +<h2>Changelog</h2> + +<h3><time>2019-07-06</time></h3> + +<p> +Add current status section. + +<h3><time>2019-05-01</time></h3> + +<p> +Fix typo: "thins" → "this". + +<h3><time>2019-03-31</time></h3> + +<ul> + + <li> + Explain why Wayland isn't (yet) the answer + + <li> + Project name updated + + <li> + Converted to HTML + + <li> + Removed explicit GPLv3 license, because CC-BY-SA 4.0 is + GPLv3-compatible + + <li> + Minor copy editing + +</ul> diff --git a/nlnet-pet-2019-03.html b/nlnet-pet-2019-03.html new file mode 100644 index 0000000..0bf02fc --- /dev/null +++ b/nlnet-pet-2019-03.html @@ -0,0 +1,423 @@ +<!doctype html> +<html lang="en"> +<head> + +<meta charset="utf-8"> +<meta name="viewport" content="width=device-width,initial-scale=1"> + +<title>Spectrum NGI Privacy grant application</title> + +<body> + +<h1>NGI Privacy grant application</h1> + +<h2>Preface</h2> + +<p> +This is an HTML version of the application I made +to <a href="https://nlnet.nl/">NLNet</a> for +a <a href="https://nlnet.nl/PET/"><abbr title="Next Generation +Internet">NGI Zero Privacy and Trust Enhancing Technologies</abbr></a> +grant. + +<p> +I would like to +thank <a href="https://mastodon.social/@rysiek">rysiek</a> for telling +me about the grant and encouraging me to apply, +and <a href="https://spacekookie.de">Katharina Fey</a> for her help in +writing the application. + +<h2>General project information</h2> + +<h3>Project name</h3> + +<p> +Spectrum + +<h3>Website / wiki</h3> + +<p> +<a href="https://spectrum-os.org">https://spectrum-os.org</a> + +<h3>Abstract</h3> + +<blockquote> + + <p> + Can you explain the <strong>whole project</strong> and its expected + outcome(s). + +</blockquote> + +<p> +Security through compartmentalization has emerged as the solution to +the problem that desktop computer users by and large don't have access +to meaningful security on their systems. + +<p> +The Spectrum system will improve significantly on many problems +affecting existing compartmentalized desktop OSes. For greater +hardware compatibility, the base system will run on the Linux kernel +rather than a server-oriented hypervisor, and there will be multiple +backends for isolated systems, from containers to virtual +machines. User data and application state will be managed centrally, +while remaining isolated, meaning that it can be backed up and managed +as a whole, rather than mixed up in several dozen VMs. The host system +and isolated environments will all be managed declaratively and +reproducibly, saving the user the burden of maintaining many different +virtual computers, allowing finer-grained resource access controls and +making it possible to verify the software running across all +environments. + +<p> +The requested funding should get Spectrum to the point of being a +usable system that realises these benefits. I am an EU citizen, and +project infrastructure and evangelism would be primarily Europe-based. + +<h3><q>Have you been involved with projects or organisations relevant + to this project before? And if so, can you tell us a bit about your + contributions?</q></h3> + +<p> +For reasons expanded on in the comparison with existing efforts, being +built on top of the Nixpkgs package repository is important to the +success of the project. I am a Nixpkgs committer, and have worked with +packaging, isolation, and configuration management as part of my work +with Nixpkgs. Recently, I helped design and implement a system to +create reproducible container images in Nixpkgs. I envisage that as +part of my work on Spectrum I will upstream a lot into Nixpkgs, +benefiting the wider ecosystem beyond this project. + +<p> +I have used QubesOS, the main existing effort in this space, as my +primary desktop operating system, and I have followed the research +done by the QubesOS team. This interest, over a period of years, has +given me a strong understanding of the intricacies of security through +compartmentalization, and the problems with existing implementations. + +<h2>Requested support</h2> + +<h3>Requested <strong>amount</strong></h3> + +<p> +€49200 + +<h3><q>Explain what the requested budget will be used for?</q></h3> + +<blockquote> + + <p> + Does the project have other funding sources, both past and present? + + <p> + Explain costs for hardware, human labor, travel cost to technical + meetings, etc. + +</blockquote> + +<p> +I expect to use the requested budget something like this. The funding +should cover one year of development, maintenance, distribution, and +promotion of the project. + +<ul> + + <li> + €2000 test and build hardware as required + + <li> + €200 for infrastructure (domain names, hosting) + + <li> + €2000 for travel for conferences, workshops, etc + + <li> + €45000 to fund my full-time development efforts for a year + +</ul> + +<p> +I plan to purchase build hardware rather than renting build servers to +protect against the threat of compromise by a malicious host. This is +the same strategy that Qubes takes. Bit-for-bit reproducible builds +would mitigate this attack vector, but the system is unlikely to be +entirely bit-for-bit reproducible, at least initially, because each +package would have to be checked for reproducibility, and development +effort would have to be put into making the non-reproducible packages +reproducible. This is valuable work, but not required for an initial +release. There is ongoing effort to make nixpkgs bit-for-bit +reproducible. + +<h3><q><strong>Compare</strong> your own project with existing or + historical efforts</q></h3> + +<blockquote> + + <p> + (e.g. what is new, more thorough or otherwise different) + +</blockquote> + +<p> +The current standard-bearer for this approach to security is +QubesOS. QubesOS runs Linux and Windows virtual machines on the Xen +hypervisor, and composites them all together into a single desktop +environment, with utility programs that allow users to manage their +complete system and control the interactions between VMs. While Qubes +has been largely successful in creating a usable system around +security by compartmentalization, its fundamental technology choices +leave a lot of room for a new approach. These choices are very deeply +embedded into Qubes, and it would be next to impossible to build a +system with the benefits I propose here on top of Qubes. + +<p> +The areas in which I propose to improve over QubesOS are: + +<h4>Installation</h4> + +<p> +Qubes is notoriously annoying to install, even on well-supported +hardware. The installer gives very little useful debugging +information, and once Qubes has been installed, no information is +recorded that would help to reinstall it. + +<p> +The installation process of NixOS, upon which Spectrum is based, is +currently a somewhat manual process — a user must partition their +disk themselves, then run some shell commands to generate a system +configuration and install the operating system. It is, however, much +more reliable than Qubes', and the effort required to make this even +easier (e.g. by including a partitioning wizard as part of the +installation process, or providing a graphical tool) would be much +less than attempting to improve the black box that is Qubes' +installation process. This is something of general interest to the +NixOS project, and so it may be that it doesn't have to be developed +as part of Spectrum. Alternatively, if it was developed for Spectrum, +it could be upstreamed and benefit the NixOS project as a whole. + +<h4>Maintenance</h4> + +<p> +Because a lot of activity on a Qubes system happens inside multiple +long-lived virtual machines, a Qubes system requires the maintenance +effort of many computer systems that must all be kept up to date, +configured, and debugged. Qubes provides some utilities to mitigate +this effort, such as TemplateVMs and a system-wide backup utility, but +it still requires a lot of effort to be kept functioning. + +<p> +One of the worst things about maintaining a Qubes system (or indeed +almost any Unix system, but Qubes is particularly affected due to +effectively being many Unix systems in one) is that, due to a system +update or a configuration change, something that had previously been +configured by the user to work correctly is now broken, and there's no +way to tell why that is. There's no way to figure out what changed, so +the user is left forced to restore a working backup (if they have +one!) and try again. Once a machine has been configured, that +configuration cannot be reproduced automatically on a reinstall or on +another computer. It very quickly becomes a black box that is +difficult to ever modify for fear of breaking it, because breakages +are catastrophically difficult to recover from. It is extremely +difficult for OS developers to debug why a user's system isn't +working, because they have no way to see the whole configuration of +the system, or why things are configured the way they are — did the +user choose this? Was it changed automatically by a program? Is it +just an old default that an operating system upgrade neglected to +change? + +Qubes attempts to solve this problem through Salt, but this is really +papering over the cracks, because Salt is not fully reproducible. Two +computers configured using the same Salt configuration can still end +up being different, if resources such as system packages hosted on the +internet have changed. Additionally, there's nothing to prevent a +Salt-configured system being modified outside of Salt, either by a +user or, worse, by a program on behalf of the user (possibly without +the user realising). + +<h4>Hardware compatibility</h4> + +<p> +Qubes is a distribution of the Xen hypervisor, and as such the Qubes +system is very tightly coupled to Xen. Xen is designed primarily for +use of servers, rather than laptops, and therefore compatibility with +personal computers, especially laptops, is very limited. + +<p> +The aspect of Spectrum most likely to be a subject of heavy discussion +is that, unlike Qubes, it offers support for container-based isolation +as well as VMs. While container-based isolation is likely to be +somewhat easier for an attacker to exploit due to the shared kernel, +container-based isolation is still valuable for the vast majority of +personal computers whose only other option is no +virtualization. Containers are very widely used, and any discovery of +a vulnerability in a container system is likely to have a huge impact +on industry and be fixed extremely quickly. A large portion of +Spectrum users are likely to be people who are uncomfortable that any +application they run can freely access all of their files, but for +whom container system zero days are not a part of the threat +model. Container-based isolation is very well suited to a user of this +kind who is unwilling or unable to acquire expensive hardware to be +able to run Qubes. + +<h4>Isolation boundaries</h4> + +<p> +The Qubes model encourages the user to create one isolated environment +for every identity or task they wish to accomplish. There might be a +"Work" environment and a "Finance" environment. This is a step in the +right direction, but in most cases it still gives software far more +access than is necessary for it to be able to do its job, putting more +data than necessary at risk in the event of any application being +compromised. There is no reason that a word processor in the "Work" +environment should be able to access the user's work mail, but Qubes +lacks the fine-grained permissions to be able to describe +this. Instead, the user must create two virtual machines, one for work +document editing, and one for work mail. To work on a word processing +document received via mail, the user must copy it to their document +editing virtual machine. The user who rightly tries to apply the +principle of least access to the applications they use is left with an +enormous list of environments for each application in each context, to +the point that there are so many environments that they are +unmanageable. Since data is stored per-environment, it becomes +virtually impossible to keep track of which environment has the +up-to-date version of the file one is looking for. + +<p> +In Spectrum, data is stored in a single directory hierarchy, so there +is a single source of truth, rather than data being scattered across +virtual machines. A user defines isolated environments for a single +application<a href="#def-application">*</a> at a time, so +there is no reason for an application to end up with far more access +than it needs. At the same time, it's not enough to be able to say +"LibreOffice should be able to access my work documents", because then +a malicious document that is available to the "Personal" workspace but +isolated from the "Work" workspace would be able to use the instance +of LibreOffice it's running in to be able to cross the security +boundary. Instead, Spectrum configuration is based around "instances" +of applications. There can be a "Work" instance of LibreOffice and a +"Personal" instance of LibreOffice. Both of those can have separate +state and have different data available, and neither of them are able +to access the user's mail. + +<p id="def-application"> +* an application in this sense is not necessarily a single +program. For graphical applications, this is likely to be the case, +but, for example, a terminal emulator is only useful if it has +programs available for the user to run. It would be more technically +correct to say that environments are configured for Nix expressions, +but "application" is easier to understand, and in most cases the user +shouldn't need to be aware of the distinction. + +<h4>Trusted computing base</h4> + +<p> +One area in which Qubes is superior to Spectrum is in the size of its +trusted computing base — the software that must be assumed to be +secure for the whole system to be secure. Qubes focuses heavily in +using as small a TCB as possible. This gives a potential attacker +fewer entry points in which they could find a vulnerability. Spectrum, +on the other hand, chooses a larger TCB for better hardware support +and ease of development, giving many more people the opportunity to +use a compartmentalized operating system. + +<hr> + +<p> +Aside from Qubes, the only other attempt of which I am aware to create +a compartmentalized desktop operating system is SubgraphOS, a +container-based system. The developers of the system manually create +containers for common desktop applications (around 20). However, there +are significant flaws with the Subgraph approach. It has no support +for multiple security domains or identities, and it provides no +additional security when using any application other than the 20 or so +which have been chosen to be manually containerized. I don't believe +that any approach which requires manual containerization can ever +succeed, because the security model falls apart as soon as the user +needs to use any slightly uncommon software. Finally, SubgraphOS has +not seen a release since an alpha version in 2017, so I don't consider +it to be a serious contender for a secure desktop operating system. + +<h3><q>What are significant technical challenges you expect to solve + during the project, if any?</q></h3> + +<p> +The major challenge in developing the system is creating an +understandable solution for configuring a Spectrum system. The model +is more complex than creating virtual machines, because there are more +concepts to understand — applications, application instances, and +state, and hardware devices. Even coming up with and implementing an +easy-to-use text-based configuration system for this is likely to be a +challenging task, and I would like there to be some sort of graphical +system as well so that the majority of users could configure the +system for their needs without having to learn Nix. Making these +concepts understandable and usable is by no means out of reach, but it +will require a novel approach. + +<p> +At a lower level, to provide support for multiple isolation backends +(VMs, container runtimes, etc.), a Nix-based abstraction layer must be +developed. Which isolation system is in use should be completely +transparent to the configuration, so that it can be changed without +requiring a whole system to be reconfigured. + +<p> +While these challenges are significant, I think the rest of the core +functionality will be reasonably straightforward to implement. A lot +of features required for a compartmentalized system — for example +displaying windows from many isolated systems on a single desktop with +unspoofable window decorations identifying which isolated system they +are running in — are solved problems now, and there are preexisting +solutions that can be easily integrated into a new system. When Qubes +was developed, this was not the case. Therefore, a year should be +ample time to integrate these existing solutions, and solve the new +problems identified above. + +<h3><q>Describe the ecosystem of the project, and how you will engage + with relevant actors and promote the outcomes?</q></h3> + +<blockquote> + + <p> + E.g. which actors will you involve? Who should run or deploy your + solution to make it a success? + +</blockquote> + +<p> +I expect to work closely with the Nixpkgs project, with which I am +already heavily involved, to promote as much work that comes out of +Spectrum as possible and to allow all users of Nix to share in some of +its benefits, without having to use a different system. There is a +sizable community around Nix already, and so it presents a good +opportunity to make people aware of Spectrum, and invite interested +people to get involved in using or developing the system early on. + +<p> +The other obvious project to engage with is Qubes. I expect this to be +more challenging, because the forums for general discussion of secure +desktop operating systems, such as the secure-desktop mailing list +started by the Qubes project, no longer appear to be active. I think +that there is a lot of potential for collaboration between the +projects, though, especially with regards to discussion about security +considerations that are shared between the two systems. I plan to try +to engage with Qubes developers and users through project discussion +channels, and also through discussions at conferences and similar +events. + +<p> +Finally, what Spectrum ultimately needs to succeed is users. The +people who are likely to use a system like Spectrum in its infancy are +people who already know about security through compartmentalization, +and already know about Qubes. I will reach these people by publishing +regular writings about Spectrum, its development progress, and its +advantages, and sharing this work online where people with these +interests are likely to see it. I will give talks about Spectrum at +relevant conferences. Longer term, I expect a userbase from this core +audience will spread awareness of the system, to the point where it +will be mentioned in any discussion of secure desktop operating +systems. This will make it easy to find for anybody who realises that +they need a secure desktop OS. The next thing to do is spread +awareness of secure desktop operating systems to the general public, +but I consider that to be beyond the scope of this proposal — before +we can spread awareness of secure desktop computing, we must first +ensure that the tools are available to actually do it. |