Dave's Bit Bucket

From the Trenches; More Fun with Trusted Solaris

As mentioned a couple of posts ago, I had a good, productive time last Friday; although it wasn't without its sessions of head-scratching. In short, the customer is looking at a traditional SNAP system (this being Sun Ray thin client-serving software and a few other things on top of Trusted Solaris 8), and wanted to arrange things such that, when a user logged in, a couple of copies of rdesktop would automatically start, with each copy being at a different label to facilitate strongly-segregated connectivity to servers on different networks.

Starting multiple copies of a service at different labels is a capability which glories in the name of polyinstantiation - however, Trusted Solaris only makes it nice and easy (using sysh, the System Shell) to do this for server applications which provide a constant service, rather than client applications which start and stop in response to user activity.

So, what's the recipe for such client-side polyinstantiation? Following much-appreciated assistance from my pal Bart (who doesn't blog, hence the absence of a link), it goes like this:

• consider the command you want to issue; in my case, it's "/usr/local/bin/rdesktop", and it's installed at ADMIN_LOW so all users can see it.
• create an executable wrapper script for each label at which you wish to issue the command; in my case, for a two-label system which had a very simple schema of LEVEL_1 and LEVEL_2 as sensitivities, and no compartments, I created /opt/rdp-l1 containing "/usr/bin/pfsh /usr/local/bin/rdesktop app-level1" and /opt/rdp-l2 containing "/usr/bin/pfsh /usr/local/bin/rdesktop app-level2" (app-level1 and app-level2 being servers to which hardwired connections needed to be made, on each segregated network).
• create a rights profile "RDP" in which /opt/rdp-l1 is given a label of LEVEL_1 and /opt/rdp-l2 is given a label of LEVEL_2, and assign the profile to all users who need to use rdesktop
• in order to have rdesktop start when any user logs in (this being what the customer wanted), edit /etc/.login to include "/opt/rdp-l1 &" and "/opt/rdp-l2 &"
• trust to user clearances such that, if a user doesn't have LEVEL_2 clearance, they can't run /opt/rdp-l2 (really, this works just fine)

Granted, editing a .login file isn't elegant. However, I failed to be able to replicate CDE desktop actions across users (and am still not sure why, to be honest), and as rdesktop needs to be started from a shell rather than by an action, any windows it has open at user logout time are not caused to persist for next login. Also, putting commands in $HOME/.dt/sessions/sessionsetc or the global equivalent in /usr/dt/$LANG/ doesn't work on Trusted Solaris, for good reasons I won't go into.

So, what happens is that .login runs at LEVEL_1 when the user logs in, and the pfsh profile shell picks up the label property of rdp-l2 to run its contents at LEVEL_2 correctly. Job done :-).

(2007-01-15 10:20:00.0) Permalink Comments [1]

Thoughts on "Web 2.0 Security"

I saw an internal presentation on Web 2.0 last week - it was mostly a very well-expressed introduction and review of basic concepts, rather than something Earth-shatteringly innovative and radical - nonetheless, it set me thinking.

Principles and Priorities

I think it's fair to say that many Web 2.0 companies have a very different approach to security, and often work to something other than the "conventional set of Enterprise rules".

The primary security-related property that Web 2.0 companies really appear to care about is availability. Service-wrecking attacks, resulting in outages and effort to rebuild, are the scenario everyone dreads most - outages or performance issues are the things most likely to cause a user to leave for good.

Blogs, Wikis and Photo / Video sites

Defacements of wikis and posting of inappropriate material to photo and video sites, or inappropriate blog comments, tend to be dealt with in "Red Army mode" by throwing people at the problem; while this has issues of scalability for Wikis and photo / video sites to a degree (the master editors at Wikipedia seem to keep remarkably well on top of the process of monitoring edits, but something incorrect or offensive can still get up to an hour of "live" time even if it's written in English), the principle with blogs is that the comments are policed by the blogger.

Ultimately, there's a human discipline involved; received wisdom is that "security is 70 percent people policy and procedure, and 30 percent what you do to the computers" and has been for as long as I've been working in the industry, but the Web 2.0 approach to defacement throws the numbers even further in favour of the human element, automatic filtering or not.

Manual blog comment filtering does scale in that "one blog = at least one blogger = at least one human filtering engine", but this only holds true when the blogger operates a discipline of regular comment review. Folk I know who have experimented significantly with automatic comment filtering have anecdotally reported varying degrees of effectiveness of such systems; Bayesian filters work to some degree, but the most effective anti-comment-spam measure appears to be blocking of the string "http://".

Also, while a blogger is required to authenticate to the blog server with at least a username and password in order to post (or delete - unauthorised deletion being a special case of availabiility issues) an entry, the only thing a commenter is (usually) required to do is pass a little test to show that they are a human rather than a machine. This mitigates the risk of "comment spambots", but does nothing to prevent someone damaging someone else's reputation by posting some offensive or daft comment in their name. While Liberty would appear to be an ideal solution to this problem, the matter remains of commenters needing to sign up with Identity Authorities to gain the ability to comment on a blog, and of blogging infrastructure owners forming reciprocal agreements with Identity Authorities to allow Liberty users to make authenticated comments, and somehow distinguish an authenticated comment from an unauthenticated comment when presented on the blog. In the fast-moving, somewhat laissez-faire philosophy that much of Web 2.0 appears to cleave to, this appears "a bit heavyweight".

Mashups

In the world of the mashup, it becomes impossible to verify that the second-hand data presented to the mashup user (eg a map from Mapquest or GetMapping via Google via the mashup to the user) has not been modified or transformed in a way which causes its accuracy to be lost (at least, without attempting the practically infeasible in terms of pursuing globally-pervasive PKI).

This may be part of the reason why so much Web 2.0 software carries a "Beta" designation, no matter how mature the mashup's code is - it hides the fact that people won't pay for something they can't treat as authoritative. Also, where a service relies on another service over which it has no control, a change in the service "further up the chain" could cause things to break unexpectedly at the point of the mashup. To put this pithily, "Beta status is inherited by dependency" :-).

Regulation

Finally, the business model of many Web 2.0 companies doesn't involve making - or indeed, dealing with, to any great degree - money. YouTube's business model was to be bought by a web giant (they made continuous losses every quarter from founding), and Google duly obliged. Any business which doesn't handle financial transactions with its users will have less onerous auditing infrastructure requirements placed upon it by regulatory bodies, and a business which does not need to interact with banks in order to transfer subscription funds, etc will need less back-end interfacing infrastructure.

I suspect this article will be getting several updates as more thoughts turn up on this :-).

Update:

I was reminded over lunch that there's one area I've failed to address; that of activities which seek to promote a website's page rank on Google or an article's ranking on Digg, etc (aka "click fraud"). I need to think about this some more and blog a suggestion or two.

Further update:

There's more. A recent lawsuit (link to be inserted when I find it) involved "misrepresentation as a consumer", where an author masqueraded as a book purchaser on amazon.com to give his own book a glowing review. Unless identities get federated from the outset, this problem will persist.

Also, my pal Efi (who doesn't blog, hence no link) gave a presentation the other day which made me realise something interesting - "Web 2.0 mashups" are almost "cross-site scripting attacks gone legitimate".

(2007-01-15 07:56:40.0) Permalink Comments [0]

Spyware for Symbian

Following a rather triumphant day's work last Friday at A Customer Who Cannot Be Named, I'm catching up on a surprisingly large email backlog.

One of the more interesting items I've been sent involves an apparent full demonstration of spyware for Symbian-based mobile 'phones; the code is apparently able to not only copy the contents of SMS messages and the numbers to which they are sent, but also track which hex the 'phone is interfacing via and - in extremis - open the microphone as an old-fashioned audio bug.

More details can be found here; at least for the time being, as the site doesn't appear to offer a permalink feature. When the site gets updated and this link becomes obsolete, search for an article dated January 12th 2007 by Dani Sinha.

I've heard a lot about the increasing maturity of technologies to track mobile 'phone locations by signal strength correlation between adjacent hexes, but this is the first I've seen about genuine spyware for handsets. Regrettably, the article doesn't discuss the vector by which the software was installed on the handset in the first place; this is something I need to look into further.

Update:

I've heard, by word of mouth from a colleague, that the spyware was manually uploaded to the handset via Bluetooth. It seems that it hasn't been incorporated into a virus at this time (but await some musings I'm writing-up on the history of, and trends in, viruses for more thoughts...)

(2007-01-15 06:23:26.0) Permalink Comments [0]