First, some news: we have a new look and feel / theme for the blog and in response to a comment from one reader (Hi William!) the "categories" - General, Alerts, News - have all been broken-out in the page header, along with links to the relevant RSS feeds for each.

So if you prefer to separate the Sun Security Alerts from the Security postings, all you need do is bookmark or subscribe to the relevant page / feed. I'd like to thank Chandan for his as-ever superb graphic tastes... Er.. yes, something like that. You know what I mean.

Second: an observation that I should really have followed-up some time ago; I run almost exclusively Solaris upon my laptops, and having developed the habit early-on for some time now I've been faffing with WiFi configuration at a fairly raw level. - I eschew the GUI convenience of inetMenu and the automation of NWAM in favour of handhacked shellscripts.

In these circumstances I have thus become more intimate than most with the output of Solaris's wifi-administration tools.

For ages I've been plagued by offers of Free Public WiFi - for that is the name of the network, one sees it everywhere - whenever I've been scanning for network access, and it finally struck me to actually look the damned things up. There were too many of these networks for them to be a legitimate enterprise.

Instantly I found a blog posting which not merely explained the phenomenon, but also outlined my extant fears and my eventual conclusion too; in short the phenomenon is not a computer-borne virus but a human-borne viral meme which is caused (enabled?) by a XP misfeature:

TechBlog

So what are these things? In doing a search, I found some references in security-related discussion groups to the phenomenon, and lots of instances of people spotting these, even on airplanes. But didn't see what I was afraid I'd find -- that this is some kind of virus or spyware that sets up an ad hoc network as a trap.

It appears to be a manifestation of a feature of Windows that I wrote about earlier this year. When Windows connects to a network, it retains that network's name, or SSID, then broadcasts its as an ad hoc network, essentially inviting a connection. You can find more details here. Microsoft has said it will fix this in the next XP service pack; it's unclear if Windows Vista behaves this way.

So why do you see so many of these? My theory: It's viral, but not a virus!

What's the thing almost everyone wants to find when they open a WiFi-enabled notebook and search for a connection? Why, free public WiFi! If you see that -- and you don't know any better -- you connect to it.

Your notebook then retains that SSID, broadcasting it as an ad hoc network. Others see you, connect to you, pick up the name, and later pass it on. And on and on it goes. Since people travel with their notebooks, it's easy for this to have moved quickly, across the country -- like a cold spreading in the closed confines of an airplane cabin. (continues...)

See also this and this.

As a student of IT security taxonomy, to me this is clearly different from all of the typical viruses, worms and trojans; I feel that 'meme' is the only remaining accurate description, although I'd welcome alternative suggestions.

- alec

tags: free public security slotd wifi wireless

Permalink | Comments [2]

Dave Walker is on of Sun's clearest thinkers on matters related to identity and access to data; about a year ago he posted this observation which didn't really get the attention it deserved.

http://blogs.sun.com/davew/entry/identity_unbound

The issue of identity has been bothering me for a while. While identity can clearly be applied to human consumers of services - and expressed as a subset of information held about them in various places - I've started wondering how the concept of identity could be used for various other entities, and indeed how the properties of identity as applied to humans could potentially be mapped onto them.

Hence the table below, which is my rather crude first shot at this mapping for files, running processes, OS instances, zones, hardware domains and services. Cells with question marks in them are areas where I currently don't see a mapping - this could mean that a mapping is not appropriate, or that an appropriate technology does not exist today, and could point the way for a bit of fundamental research.

I suspect I'm heading down a path which has been well-trodden already, but you might find some parts of this amusing. I'd be happy to bounce ideas around, or become clueful on what current thinking in this area actually is.

(continues...)

I'm hoping to get Dave blogging here more directly, soon, so keep an eye open.

Treating processes (ie: computer programs, live and running on a CPU) as if they were people, is not necessarily as easy as you might think - but then given how easily some people can be socially engineered maybe it's not so bad an analogy after all.

tags: identity security slotd

Permalink | Comments [0]

At the London OpenSolaris User Group meeting after the recent London Sun Tech Days event there were a few people asking questions about Solaris and Microsoft Windows interoperability. I stepped up to the plate to answer these since mostly they were around Active Directory interoperability and in a former job at I Sun I did my fair share of name services related work; also a lot of the integration work that is being done is based on lining up the security/authentication protocols between Solaris and Active Directory so even though I'm not actively working on it I have been in regular contact with the developers who are.

One of the biggest favours I personally think Microsoft did the security community was choosing to use Kerberos as a core part of the security layers in Active Directory, particularly now that the PAC data format is documented. The Solaris Kerberos development team did a lot of work getting the base Kerberos functionality in Solaris to work better with Windows, by ensuring that cipher suites lined up, password change works and like Windows we could look in DNS to find the KDC and REALM information.

Just having working Kerberos is not enough for most people, in many cases what they really need is for their Solaris machine to "appear" to Active Directory "just like a Windows XP" machine would. That means that Solaris has to use LDAP as the name service. Well thats easy you say Solaris 8 supported that, not so fast! Its all about the schema and how it is used.

There are a few OpenSolaris projects that are working specifically on the name service client side of Solaris to make it a better Active Directory client. Those projects are: Sparks, Reno, Duckwater and Winchester. The Sparks project page has a good technical overview diagram of how it all fits together. Some of these have delivered all or part of their functionality to OpenSolaris already but the full picture is still in development. I look forward to the day when I can post here "It just works", in the mean time hold on in there, "we" are working on it!

- Darren

tags: active directory microsoft slotd

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]

Bonus Link Tuesday :-) instead of just one link of the day I'm going to highlight a few recent security relevant ARC cases. For information on what an "ARC Case" is see the ARC community on OpenSolaris.org, at a high level it is how we do reviews of things users/admins/developers can see and use in (Open)Solaris and document the interfaces and their interactions.

The first two are proposals that are currently still in review so they functionality they describe doesn't yet appear in any OpenSolaris distribution.

First one is a proposal (PSARC/2007/200) to change the way that IPsec is started up by making better use of SMF, this gives better fault recovery - something really important when securing your system. Plus I logged the bug for this and provided a first suggestion at the new SMF services, and I'm really glad to see the project getting implemented now. The proposal is much more complete than my original suggestion and provides a very nice set of new SMF services that shows much better how IPsec works instead of it being "hidden" as part of general networking services.

The second one (PSARC/2007/198) is related to how IPfilter and IPMP work together. I find this one quite interesting because it focuses on how statefull packet filtering works in a high availability networking configuration. It is also interesting because this proposal is actually a short term solution that is to be provided until the Clearview networking project is ready.

My third and final link for today is a really geeky and quite low level/internal feature of the Cryptographic Framework. It (PSARC/2007/093) is about sharing the context (state) of in progress multi-part crypto operations between hardware and software providers.The real end user benefit of this better performance. This is because sometimes it is actually faster to run the software version of an algorithm than to send small data sizes out to dedicated crypto hardware. I'm not aware of any other operating system with a crypto framework that goes to these extents to get the best crypto performance out of the system as a whole; I'd be very interested in learning about others (particularly open source ones) that do similar things. I've long said to my team mates in the crypto group that there is a PhD thesis to be written about crypto job scheduling for best single throughput versus best system load with different mixes of hardware and software crypto engines.

That's it for day, - Darren.

tags: arc opensolaris psarc slotd

Permalink | Comments [0]

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]

So what happens if by hook or by crook someone breaks into your Solaris system and installs a trojan horse? Modifies the password file? Deletes a few old logfiles?

Or what if you run a heavily change-controlled system environment, and you need to know whether anything has been changed outside of the scope of your operational processes?

There's a solution built-in to Solaris 10: bart - Basic Audit & Reporting Tool, a truly boringly-named tool which does something both useful and interesting:

BART provides a quick and easy way to collect information on filesystem objects and their attributes so that, at a later time, you can determine whether there have been any changes. BART can help you detect accidental or malicious changes to files within an operating system due to either a security incident or change management incident.

BART is able to collect such information as an object's UID, GID, permissions, access control lists, modification time, size, and type. In addition, for files, BART generates an MD5 fingerprint from the contents of the file. For a full list of the attributes that can be collected, see the bart_rules(4) manual page.

There's a lovely white paper "blue print" explaining all this, available for download (nb: PDF document ; apparently HTML was neither pretty enough nor impressive enough) along with the rest of the Sun Security BluePrints some of which we'll be spolighting individually over the next few weeks.

- Alec

tags: bart security signatures slotd sun

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]

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]