Friday Apr 20, 2007

SLOTD: Trusted Extensions: Ready for Commercial Prime Time

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 (for laptops).

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 notable 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 web browsing (which is ideal for the laptop case above), and is working on multilevel mail.

Update:

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 :-)

-Dave

Wednesday Mar 28, 2007

2007-03-29 Security Link Of The Day

Glenn Faden is one of Sun's hardline security geeks, the prime mover behind the Solaris Trusted Extensions project which succeeds the older Trusted Solaris.

Glenn writes:

I have been working on an architecture for multilevel mail in Trusted Extensions in which mail can be delivered to labeled zones that are only in the ready state (mounted but not running). This would reduce the overhead of the current polyinstantiation approach in which an instance of sendmail is running in each zone.

For those unfamiliar with "trusted platforms", their core concept of "labelling" is to mark each file, directory, object, process or person on a machine with both a "compartment" (eg: finance, IT, payroll, human-resources) and some sort of "sensitivity" (eg: unclassified, confidential, secret); the trusted functionality permits "label-aware" applications to enforce need-to-know information handling rules.

That may sound outre or faintly military ("top secret") but there are dozens of possibilities for systems where you can keep programs aloof from each other, or from the data which they are processing.

Consider a webserver with one Internet-facing network interface, and another network interface attached to your credit-card database. Wouldn't it be nice to be assured that no data can pass from your credit-card data through to the Internet without being specially filtered, brokered and sanity checked? I find the idea rather appealing, I must admit.

Or consider the possibility of multilevel Instant Messenger - there would be no cut-and-paste between internal IM and external AIM, Yahoo or Skype; that really gets some finance people (eg: the sort who deal with traders) rather excited...

- alec

About

This blog provides security vulnerability fix notifications relevant to third party software components distributed and supported as part of Oracle Products.
Summarized version of this blog is available as a mapping of CVEs and solutions.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
2
3
4
5
6
7
8
9
10
11
12
13
14
16
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today