Historically, Trusted Solaris was a completely separate environment
from "regular" Solaris. The Solaris 10 11/06 production release finally
broke the mould, when Trusted
Extensions integrated into the main Solaris release. Granted, the
packages which need to be installed on the top of an unlabelled Solaris
10 install still need to be installed using an extra install tool, but
you'll nonetheless find them on the regular distribution media under
the Solaris_10/ExtraValue/CoBundled directory, right alongside the
SunVTS hardware validation test suite.
Configuring everything once the packages are in place is a more
interesting proposition, but there's a good recipe here
We make no bones about the fact that Trusted Solaris began life as an
engineering project for the US Government, first went live 17 years
ago, and has seen little use in the commercial world (with one or two
exceptions) by its nature as a separate product with military
heritage ever since - however, now that it's no longer a separate
product, we believe that the time is right for commercial adoption.
To this effect, we've been looking at some of the areas in the
commercial world where its capabilities have a natural fit. So far, the
partial list looks like:
- Grid segregation: Where a multi-tenant grid within an
organisation or consortium is required, such that data associated with
one set of users is very rigorously segregated from data associated
with another set of users. Have a label per tenant organisation, and
run Grid Engine within the zones associated with the labels. Academia
may find this interesting, as may some areas of Financial Services (eg
where Chinese walls have to be maintained).
- Datacentre Base Services consolidation: Trusted Extensions
makes the perfect multi-client-organisation NTP server (see http://blogs.sun.com/davew/entry/tempus_fugit_addendum)
- apply "labels" as "zones" :-). Given the way that both DNS and NTP
work (in terms of "client fails gracefully to next nominated server if
previous is unavailable"), clustering wouldn't be a concern - or DNS
could be load-balanced in the network. Co-location service providers
would find this interesting, especially where separation of services
between customers is required to be rigorous.
- Laptop security: Consider the well-known issues of
open-access wireless for folk working "out in the world" who
nonetheless need to communicate with the office. Walk into your nearest
Starbucks, connect to the untrusted wireless at PUBLIC, establish a VPN
over the top of that at CONFIDENTIAL (or whatever label you want your
corporate intranet to be treated as), job done. I gather Glenn Faden already works this
way; Darren also suggested
the elegant further finessing of making the PUBLIC zone whole-root so
that the VPN packages could be removed from it :-). Such a solution
would likely find interest with "everybody who carries sensitive data
on a laptop and uses third-party networks".
- Segregation of CCTV server feeds and archives: We have a
solution in trials for using our servers as an aggregation and analysis
point for good-sized numbers of IP-based CCTV feeds. I think Trusted
Extensions could have a valuable part to play in terms of segregating
feeds associated with multiple businesses from eachother, and tightly
controlling which users are allowed to see feeds from which cameras.
So, that's my short list as it stands today - Glenn Faden has
prototypes already for safe
(which is ideal for the laptop case above), and is
working on multilevel
If we extend this a little further, we have:
Any organisation where leakage of internal data is an issue could benefit from having a simple, two-label system of "Public" dominated by "Internal", where "Public" is the Internet connection and "Internal" is the Intranet. If all users are (as is the default) denied permission to downgrade data, then it becomes much more unlikely that internal data will leak. Giving users the ability to upgrade data by default still allows external data to be brought internal. This works well even when organisations do not differentiate between classifications of internal materials, and the Safe Browsing mechanism comes into its own, when web sites on the intranet need to make pointers to materials in the wider world.Press Officer and Auditor roles could also be created, which would potentially be the only roles allowed to downgrade data as part of the external release process.
In educational establishments, denying the ability to upgrade and downgrade data means that while a number of websites can readily be viewed (assuming filtering software is already in place on the Internet link), data can't readily be plagiarised using cut and paste from external sources into essays, etc. Also, if Public and Internal zones are installed as whole-root rather than sparse-root zones, such that careful use of pkgrm can subsequently be used to deny access to internal tools (such as IM) in an external context, so cyber-bullying could be more readily tracked; bullies wouldn't be able to create anonymous / pseudonymous external accounts "on the fly" from which to abuse their victims.
As well as co-location facilities, law firms may wish to extend their "duty of care" capability, in terms of ensuring segregation of client data, by having a compartmented label per client.
If you have some more ideas, please add them in a comment :-)