Tuesday Jul 22, 2008

Solaris 10 11/06 achives Common Criteria EAL4+ CAPP/RBACPP/LSPP

Solaris 10 11/06 now has a Common Criteria EAL4+ certification for CAPP/RBACPP/LSPP. For full details see the press release. Details of all Solaris Common Criteria certifications are available on the security certifications page.

- Darren

Monday Jul 30, 2007

Trusted Extensions now open and core

Trusted Extensions binaries have been part of Solaris since the 3rd update release of Solaris 10. Over the weekend Trusted Extensions entered a new and very exciting era. Not only is it now part of the Solaris 10 binary product but there were two signficant changes.

  • First the packages are no longer extra and are always installed. Turning on Trusted Extensions is now just a matter of starting the labeling service: 'svcadm enable labeld'. This architecture change is discussed in PSARC/2006/254.
  • Secondly the source code to what was previously called the "TLC" gate migrated into the ON gate. Most of this is in usr/src - ie it is open and under the CDDL license. However there is one part that ended up in usr/closed and that is labeld. The information on how to call labeld is open so in theory other distros could create their own replacement daemon.
This is just the first part, the corresponding changes need to happen for the TX supplementary code for the other consolidations including JDS.

- Darren

Tuesday Jun 12, 2007

SLOTD: A couple of security podcasts

A couple of podcasts on various security topics can be found on sun.com/security

The Systemic Security recording is of Hal Stern talking to Glenn Brunette about what we're building, documenting and sharing to (help) make everything that gets deployed more secure.

In the Solaris podcast they are joined by Darren Moffatt, and chat about what security features we have in Solaris (crypto, Trusted Extensions, RBAC...) and what will be coming in the future.

Ellyptic Curve Cryptography is the topic of the third podcast, this time with Hal discussing matters withVipul Gupta. After an overview of what ECC is, they look at the interoperability aspects of these algorithms.

Update: To hear another voice -- Joel Weise's -- on one of the topics Hal raised in those podcasts there's the systemic security "Net Talk" programme.


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.


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


Sunday Apr 01, 2007

Security Link Of The Day: Reponse to Trusted Extensions vs RHEL

Karl MacMillan has blogged a response to Glenn Faden's comparison of Trusted Extensions and SE Linux as used in RHEL5 for LSPP(Labeled Security Protection Profile).

I almost stopped reading after the first few paragraphs though because of the discussion about the use of "Trusted". In reality "Trusted Extensions" is really "Bell LaPadula Model Label Services" but that just doesn't roll off the tongue that easily nor does it build on the "Trusted Solaris" brand and show the relationship. "Trusted" for Solaris is about as meaning full as "Security Enhanced" for Linux :-) So the main reasons we use the "Trusted" moniker is marketing and brand awareness, and no I'm not in marketing :-)

There are already some comments on Karl's blog from Glenn clarifying some points as well as some from David Comay about the overhead of Zones. Great to see this type of discussion happen in the open between the two communities. Hopefully a better understanding and scope for future collaboration is the outcome for all, particularly in the networking areas around IPsec.

- Darren

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


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.


« July 2016