Tuesday Jul 22, 2008
Monday Jul 30, 2007
By Darren Moffat-Oracle on Jul 30, 2007
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.
Tuesday Jun 12, 2007
By bartbl on Jun 12, 2007
A couple of podcasts on various security topics can be found on sun.com/security
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
By davew on Apr 20, 2007
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.
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
Wednesday Mar 28, 2007
By alecm on Mar 28, 2007
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...
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.
- CVE-2014-7185 Integer overflow vulnerability in Python
- CVE-2014-0119 Permissions, Privileges, and Access Control vulnerability in Apache Tomcat
- CVE-2014-0099 Numeric Errors vulnerability in Apache Tomcat
- CVE-2014-0096 Permissions, Privileges, and Access Control vulnerability in Apache Tomcat
- CVE-2014-0075 Numeric Errors vulnerability in Apache Tomcat
- Multiple vulnerabilities in Apache Tomcat
- Multiple vulnerabilities in X.Org
- Important announcement about Third Party Bulletin
- Multiple vulnerabilities in NTP
- Multiple vulnerabilities fixed in Firefox 24.7.0 ESR