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

tags: extensions security slotd solaris trusted

Permalink | Comments [0]

One of the great, obvious, simple ideas which went into Solaris 10 was the Reduced Networking Cluster; after fragmenting and massaging the core Solaris packages a bit, it became possible to offer a clean, minimal, even spartan installation of Solaris, a lightweight foundation upon which software could be added as and when only necessary, leading to a very tiny and yet supported machine configuration.

A colleague recently asked me for more information about the Reduced Networking Cluster, and frankly I was stumped, and then Glenn Brunette piped up that he'd written all about it back in 2004:-

The topic for this article is the Solaris 10 Reduced Networking Software Group (also commonly known as the Solaris 10 Reduced Networking Meta Cluster). This software group is new and joins the five existing software groups available in Solaris today: Core, End User, Developer, Entire and Entire + OEM software groups. The Reduced Networking Software Group is positioned as a subset of Core and represents the smallest amount of Solaris that can or should be installed and have a working and supported system. Note that for support reasons, it is not advised to remove packages installed by the Reduced Networking Software Group.

To install the Reduced Networking Software Group, simply select it from the list when doing a graphical installation. If you are using JumpStart, then you should use the cluster keyword with the new value SUNWCrnet. The following is a sample JumpStart profile that uses the Reduced Networking Software Group. This profile was also used to build the system used as an example in this article.

[...]

Yes, it's true - the size of this installation is just a little over 150-Mbytes. Note that this size is based on the build of Solaris 10 that I was using and will certainly change before Solaris 10 is finalized, but I did want to mention it as an example of how small a Solaris installation can be.

...etc; it's quite a long article but worthwhile, since it's one of the sadly few documents which look at this feature from an architectural perspective.

So, folks, if you are into Minimized Solaris Configurations, you want to start with "SUNWCrnet". Less really is more, and it costs you nothing. :-)

-Alec

tags: minimisation minimised minimization minimized security slotd solaris sunwcrnet

Permalink | Comments [0]

Something a little different for today; my boss wrote to me regards some slideware:

Alec, I'd like to identify some aspects to trends in Security. Have you observed particular security trends for web computing?

...and this is my response. I'll be mailing him the URL. You get to see it first. :-)

So, have I observed particular security trends in Web Computing?

Not really, for reasons which I partially explain in a recent posting on my home blog - the short version being that I believe there are no new security bugs, ever, and from this it's a pretty easy step to declaring security to be a "solved problem", although that carries the proviso: "if and only if you bother to hire people who understand security".

So if we want to write about the state of the art of "security and web computing" then I feel we should do it in terms of the "maturation" of Web Computing technologies.

Twenty years of geekery has taught me all technologies go though a wild-and-insecure phase until the implementational goofs instilled by the visionaries get hammered out by the embarrassment of exploits, and the needs of business. How often do you see websites which still use plaintext password cookies in anger? Yes, some people still goof in implementation, but at least a large body of people now recognise that such design and implementation artifacts are goofs.

For the people who don't know this, there are always consultants who can help. :-)

So my thesis would be: people are getting used to the idea that perhaps mashups need a little more thought than "we'll just glue it together and it will work OK"; also people are finally getting to understand that the concept of "security" is bogus, being as it is actually an umbrella term for a bunch of qualities, including but not restricted to:

• integrity
• availability
• privacy and secrecy
• trustworthiness
• privilege separation and enforcement, leveraging all of
  • authentication,
  • authorization and
  • identity
  • and all of the other stuff above, plus finally and most important of all...
• wisdom regarding the creation of security policy, and consequent design and implementation

So as we move into an age of maturation of web technologies, attitudes and received wisdom are starting to shift; people are now less scared of letting just anyone write all over their website so long as you know who it is that is doing it, and people are beginning to realise that by replacing barriers-to-creation with knowledge-of-authorship (ie: identity, authentication, authorization) - plus the additional ability to 'roll back' so you can circumvent the expected but surviable inevitable vandalism - people realise you can now invite the world to create content with you.

Sufficient technologies to solve all extant security problems now exist - modulo the chest-beating efforts of vendors to pitch new solutions to problems which they hope people will encounter - but from my perspective it's the shift in peoples' attitudes to security which is most interesting.

"Forget prior restraint and access control, build trust, identity and integrity instead."

I find that exciting; it's always been possible, but twenty years ago had you stated it was your goal, people would say you were nuts.

tags: identity mashup security solaris web web2.0

Permalink | Comments [0]

We like ZFS.

Lots of people like ZFS.

Even Linux people are experimenting with ZFS, albeit as a user-space filesystem.

ZFS is good.

But ZFS will be even better when you can have encrypted filesystems.

So maybe check out OpenSolaris.org and see if you'ld like to help-out with the project ?

- alec

tags: encryption security slotd solaris zfs

Permalink | Comments [2]

Time to bang my own trumpet - occasionally I receive requests to address a particular customer's requirement, viz: three strikes lockout where if a person fails to log in to a system (eg: mistyping a password) - and if they fail to log-in three times in succession, then some manner of portcullis drops and the resource is barred from further access. The account gets locked, in the same-old way that was popular on even-then-antiquated mainframes back when I was a student, some 20 years ago.

So I wrote this explanation of my thoughts upon the matter:

"Three-Strikes" Password Security Considered Antiquated, Hazardous, Stupid and Wrong.

(...deletia...)

The problems of "three-strikes" in the modern enterprise environment are legion: in modern distributed authentication directories - NIS, LDAP, etc - there is no typically no central authority who is counting the number of failed authentication attempts, generally for technical reasons. For example: LDAP is deeply sub-optimal for poking little bits of data like that back to a central place, for immediate propagation to all replicas. No immediacy == no security.

Even if there were a central authority that brokered this sort of information it would be subject to flooding attacks by miscreants who could tie-up that one service and thereby prevent anyone from authenticating in your enterpise, with significant business impact.

You cannot architect around this risk by including a "timeout" or other "we've tried checking whether the user has struck-out but got no reply, so we'll let him in anyway" mechanism, because that defeats the whole point of the policy.

Anyway - what merits being called "authentication" nowadays? Would you like it if you changed your system password, and then - having walked away for a coffee - your automatic IMAP-enabled mail client goofed-up three authentications and locked you out of your own system because you forgot to update the client?

(continues...)

- Alec

tags: passwords security slotd solaris strikes three

Permalink | Comments [0]

Another one in the "in case you missed it" category - Glenn Brunette on How to enable 'snoop' in non-global zones; it also serves as a useful primer about the use of limit privilege sets in zones - check out the article by Rich Teer for a more in-depth explanation.

I see you! snoop(1M)'ing in non-global zones!

Today's article talks about how to enable snoop(1M) in a non-global (or local) zone. In Solaris 10 today, the ability to use the snoop(1M) command or any other packet sniffer for that matter is restricted to the global zone. There is no way to snoop traffic from within a zone. Enter the Configurable Privileges for Zones project which integrated into Nevada build 37 and of course is available in OpenSolaris today.

Using this project and a little device manipulation, you can today get snoop working in a non-global zone, and here is how to do it... But first, a few warnings:

WARNING #1: This approach will allow the local zone to see all of the network traffic associated with the device that is added. Unless you use separate network interfaces for the global zone and other non-global zones, this means that following these instructions will allow a zone to see traffic intended for or exchanged with another zone.

WARNING #2: This approach is likely not generally recommended. This is meant only as an illustration of what can be done and may serve as a useful workaround in some environments until a more recommended, secure and supportable solution is available.

(continues...)

- Alec

tags: privileges security slotd snoop solaris zones

Permalink | Comments [0]

Scary Dave scribed thusly, back in November:

Dave's Bit Bucket

I had a rather illuminating discussion with A Really Big Customer a little while back, in the context of a Really Big Project they are working on.

The customer have an issue which states that they are getting worried about "not having an IDS solution on Solaris 10". In terms of IDS, they are typically an ISS shop - they want something agent-based which will do centralised reporting and alerting on perceived usage anomalies.

It turns out that only one IDS vendor - this being Prelude, about whom the customer knew nothing - currently do an agent for Solaris 10. From their perspective, this is "a bit of a bugger".

Now, in my (moderately) humble opinion, there are only three reasons why an organisation would consider having IDS in the first place...

1. Most of the time folk talk to be about IDS, they are working from a mechanistic risk evaluation and mitigation analysis system such as One I Won't Name Here which gets used when designing lots of Government stuff. This approach sometimes takes people down a technology path which might not be appropriate for them, and IDS isn't for everyone.

2. Consider that IDS doesn't actually secure anything - it merely alerts an admin team to its belief that an environment is under attack. I've met a very few folk who want IDS because they have their entire underlying security infrastructure well and truly organised, and want to add IDS as not so much "the icing on the cake" as the "100s and 1000s and the cherry on top".

3. Plain, simple pointy-haired stupidity, usually from some senior manager who just came back from Infosecurity or some other major show with a big wedge of brochures.

I don't find many folk (only two so far) in the situation of 2, and there's a lot more in 1. There's even more folk in 3. Really, IDS is only worth considering if everything else is nailed down properly already.

So, I was fortunate enough to get around a table with some senior geeks in the customer's admin and IDS department, and thrash a few things out in a forum where honesty ruled and political correctness was pretty much left at the door.

Things went roughly like this...

article continues on Dave's site...

tags: detection ids intrusion security slotd solaris

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]

Solaris is - to the best of my knowledge - unique amongst Unix impementations in having a pluggable password encryption routine so that the administrator has the option of selecting a non-default password hash routine with the hope of making yourself more proof against password cracking - plus you can migrate users off-off older, weaker algorithms in a smooth fashion.

Brendan Gregg took this to the point of extreme silliness when he implemented a ROT13 password-hashing module for which he's posted the source; if you're not familiar with ROT13 it's the most trivial of pencil-and-paper ciphers, the sort of thing which got used to hide the punchlines of jokes posted via e-mail or on USENET.

I wouldn't recommend rolling out Brendan's code in an enterprise deployment - not unless you want all your passwords cracked in about 3 milliseconds flat - but it makes a nice proof of concept, and shows what you are free to do with the pluggable crypt API.

- alec

tags: crypt password rot13 security slotd solaris

Permalink | Comments [4]

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

tags: extensions labeling labelling security slotd solaris trusted

Permalink | Comments [0]

As our first Security Link Of The Day we'd really like to mention OpenSolaris and specifically the security communities and projects within it; there are over a score of projects including (but not limited to!) the following categories:

• Cryptographic Framework (abstract access to accelerated cryptography)
• IPsec (secure TCP/IP networking)
• Kerberos (single sign-on solution)
• SASL (simple authentication security layer, framework for authentication / authorization in internet protocols)
• SSH (secure shell, encrypted interactive access with tunneling)
• RBAC (role-based access control, constraining privileged user access)
• Solaris Auditing (audit trail of user activity)
• Trusted Extensions (compartmentalisation and labelling of user data and processes)

The best jumping-off points to investigate all the security possibilities are probably the Security Community Wiki and the main OpenSolaris Projects List.

Do take a look. There's a lot of nifty stuff there.

- alec

tags: opensolaris security slotd solaris

Permalink | Comments [0]