Sun Security Blog
|
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 tags: capp common criteria lspp rbacpp solaris trusted Permalink | Comments [0]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.
- Darren tags: opensolaris security solaris trusted Permalink | Comments [0]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. -Bart tags: cryptography ecc podcast security solaris trusted Permalink | Comments [1]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:
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 :-)
tags: extensions security slotd solaris trusted Permalink | Comments [0]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 tags: rhel selinux solaris soltd trusted Permalink | Comments [1]
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.
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 tags: extensions labeling labelling security slotd solaris trusted Permalink | Comments [0] |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||