Only you can prevent forest fires

You say you want a revolution
Well, you know
We all want to change the world
You tell me that it's evolution
Well, you know
We all want to change the world
-- John Lennon, The Beatles

Ted Tso has a blog post commenting about the market capitalization of Sun (stock ticker: JAVA) being 'underwater' relative to its cash on hand:

Sun’s current market cap: $2.40 billion USD. Sun’s cash on hand: $2.63 billion USD

and advancing a concern that a firm hostile to Software Freedom might purchase and kill it. [A bit ironic, thinking about the Cobalt Qube; a PFY I trained a few years ago moved to Portland to work supporting the Qube software, only to have Sun functionally kill the Cobalt product within the year ... oops]

Not surprisingly, there is a maze of intellectual property rights to navigate in considering using an asset so valuable that a company renames its Wall Street 'nickname' from 'SUNW' ("Stanford University Network Workstation") to JAVA

Hopefully, Ted Tso was just playing 'Devil's Advocate' earlier this year in a thread of debate surrounding a proposed adoption of a java (Sun's 'Java' or otherwise) into the Linux standards base upcoming ver. 4.0 release stirred concern

Reviewing the bidding;

• LSB weekly conference call chair Jeff Licquia stated the non-Free (OSI or FSF wise) Java Test Conformance Kit concisely in the post call minutes

Jeff: summary, Ted: do a checkpoint two weeks from now, to see that the features are getting in. Jeff: agenda item for August 13th call? Ted: yes. Mats: Java is also an issue. Ted: issues with Java? Mats: which spec? Required methods, classes, etc. Test suite question is also a big deal. Ted: should follow up on these issues before Ron gets back

LSB Committee work happens in part on the mailing list.

• The thread sharpening the Sun Java issues in advance of that call kicked off here
• Alan Cox questioned the wisdom of such an inclusion of a java
• I put together a rather large piece detailing some issues surrounding the present Sun licenses as to distribution of the [Sun] Java's actually in use today as well as the accessing and using the TCK

Note: If one wants the flavor of the thread, read the posts by Tso, Cox and Herrold out of the pipermail archive for August 2008. At one point in that thread, I was asked: Why do you care. I care because FOSS culture matters and needs defenders to stand up and advocate for it. I can live with the balloting results for the 4.0 release

Software Freedom issues are an 'elephant in the room' at the Linux Foundation (current 'owners' of the LSB), and they try to thread a delicate balance to draw the commercial into the FOSS world

My personal opinion is that LF need not worry so: The 'should we have a FOSS strategy' discussion is over; 'of course,' being the outcome. Market forces will solve adoption because the firms in an given industry NOT using FOSS properly will have higher cost structures, and go extinct

Oh, and you too can make a difference; by showing up, participating with considered intent, doing justice, loving kindness, and walking humbly, all the while remembering that "politics ain’t beanball"

Behind Blue Eyes

Dateline: U.S. Department of Labor

The largest increases in initial claims for the week ending Nov. 1 were in Ohio (+3,885), Michigan (+2,619), Pennsylvania (+2,155), Wisconsin(+2,119) ...
-- UNEMPLOYMENT INSURANCE WEEKLY CLAIMS REPORT (week ending Nov. 8 2008)

A friend wrote:

All this proves is that when someone crosses a state line to register to vote it is just as easy to register for unemployment while you're at it.

I think it is probably much worse than that

It is easy enough for anyone to set up a (several!) new 'employers' and then walk away from them 8 weeks later with no individual financial responsibility for the 'tail' -- after all, we encourages formation of 'small business, the engine of economic growth' and barriers to entry should be small, right?

Unemployment benefits may be had at full rate for 6 months after 6 weeks employment at a given 'employer' if one is otherwise qualified; when an 'employer' goes out of business, the employees are eligible for benefits Several telephone poles in central Ohio had signs, with differing phone numbers, for what appeared to be short term 'jobs' working to elect Obama and 'make Change'. I snapped a picture with my mobile device, and will see if I can find it for the exact text; I recall thinking at the time:

-- Don't the 'employee candidates' KNOW they will be let go the day after the election

Now, I think the answer is:

-- Sure -- indeed they were TOLD by the recruiter at the other end of the phone, that this was a way to get rid of a pesky 'termination for cause' {disqualifying} black mark which was keeping them from what they were 'entitled to'

As the One won, and 'We can do it!' if the system is properly 'gamed', I think there will be no investigations after Jan 20 to 'connect the dots', and the Lame One will just snooze out his term. 'No law will prevent it'

And so the Republic was lost. "Meet the new boss; same as the old boss"

rpm -import of GPG keys, revisited

Okay, I guess I covered too much too fast last time I discussed adding a signing key to RPM. Let's do it again with more annotation and color commentary.

The RPM package manager (see: the old RPM.ORG website, which I maintained as 'rpm.org' for several years; JBJ's 'way forward' for RPM development site; and the rather sparse, intentionally stale, and to me useless site controlled by and populated to suit the Red Hat corporate agenda -- details of the fork in RPM are out of scope here) has the capability to verify through strong cryptography that a package is intact, and is counter-signed by a person in possession both halves of an asymmetric public and private keypair. Assuming that reasonable care (where 'reasonable' is a very large and paranoid number) is used to protect the confidential nature of the private half, the chances of a successful substitution are vanishingly small.

Anyone can examine and inventory the keys in RPM's trusted keystore. The process of additions, changes, and deletions of keys is an operation requiring root level privileges, and so assuming a machine can be trusted (both network level and local physical level attacks need to be considered)

Enumerate the keys present:

$ rpm -qa gpg\*

Examine a specific key:

$ rpm -qi gpg-pubkey-e8562897-459f07a4

If we know or can determine the 'fingerprint' of the public half of a signing key, and if that key has been placed at a public keyserver, we can retrieve it, examine it, or even directly import it. For the sake of this example, we again consider the Raw Hide SRPM signing key (with the re-organizations over time, Red Hat presently signs Raw Hide content with key: 0x4F2A6FD2 which the MIT keyserver identifies thus)

The CGI query on the link above used the 'op=index' modifier; the next uses the 'op=get' -- one assumes 'op' is shorthand for the type of query operation made -- terse, or key-bearing. In any event, we retrieve the key into a local file thus:

$ wget -O fedora-key "http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4F2A6FD2"

and then may examine it with the conventional 'nix tools:

$ less fedora-key
<title>Public Key Server -- Get ``0x4F2A6FD2
''</title><p>
<h1>Public Key Server -- Get ``0x4F2A6FD2
''</h1><p>
<pre>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP Key Server 0.9.6

mQGiBD+dnTsRBACwnlz4AhctOLlVBAsq+RaU82nb5P3bD1YJJpsAce1Ckd2sBUOJ
D11NUCqH8c7EctOquOZ5zTcWxHiWWbLyKQwUw2SUvnWa5SSbi8kI8q9MTPsPvhwt
... snip ...
r/T7zLrJeiljDxvX+6TyawyWQngF6v1Hq6FRV0O0bOp9Npt5zqCbDGs/iE4EGBEC
AAYFAj+dnTwAEgkQtEJp0E8qb9IHZUdQRwABAf/+AJwNVicN6A0I7EOfWx50PDHD
7SHw5wCfUJkeh/XlCrGdPASe/AXZB44jl2c=
=aXEw
-----END PGP PUBLIC KEY BLOCK-----
</pre>

The important thing to notice, amid the HTML markup, is that the key is 'armoured text' well set off with start and end markers, so that GnuPG (and also RPM) may pick the key out of the chaff.

We discussed previously the chain of steps we used to decide that the key was authentic, and worthy of trust; as such we do not repeat them here.

Then, using the 'sudo' command to temporarily attain 'root' rights for the importation step, we can insert (import into the RPM database) the locally checked key:

$ sudo rpm -import fedora-key

Or, assuming that we will do a post-insertion check, we can do the import directly from the keyserver:

$ sudo rpm -import "http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4F2A6FD2"

Then we can re-inventory keys, and see the new one present, and the full name under which it may be found; part of the name is, conveniently, the 'fingerprint' of that key.

$ rpm -qa gpg\*
$ rpm -qi gpg-pubkey-4f2a6fd2-3fcdf8c9

Hopefully this clears things up a bit.

Going, going, gone ...

They paved paradise and put up a parkin' lot
With a pink hotel, a boutique, and a swingin' hot spot
Don't it always seem to go
That you don't know what you got till it's gone
They paved paradise and put up a parkin' lot

-- Joni Mitchell

I flew into Phoenix for a week's rest, and was unpleasantly confronted with America West USAir's 15 dollar baggage check flying in. Took the SuperShuttle up to Scottsdale, and had a driver on his third day on the job for them. We were seeing part of the Valley new to him, anyway.

He drove a route up Scottsdale past the site of the former Raw Hide Western Town and Steakhouse. It has been gone three years now. The old site was bull-dozed flat, but it looks as though the developer who started condo construction ran out of money half-way through the project.

Dinner early in the week up in Carefree was to be at Crazy Ed's 'Satisfied Frog' -- its menu has the old saw about how 'it is so popular, no-one goes there anymore'. Last time, we ate at 'The Horny Toad' (as I recall Ed lost the Toad in a divorce; his ex kept running the place). Drove in from the west after a visit to Fry's Electronics on Thunderbird. Gone -- an imposter with new signage in its place -- google says I missed the close by a month.

Drove up to Page AZ for a wonderful nature hike in a private 'slot canyon' with Overland Canyon Tours and photo session [highly recommended and well worth the premium price]; on the way back decided to stop in Sedona for a nice dinner, and found that the high end restaurant we dined at a year ago May had closed doors; at least there is a new bank branch in its place.

Oh yes -- and two traffic circles -- a new concept there; their City Engineer must have heard how great they are -- on State Route 89 inside the city limits, and another four or five on the way back toward I-17 south of town. As traffic circles are a foreign concept, each cardinal entry point had illuminated, gas generator powered signage explaining their use. The fumes and noise are only remporary, right?

Well, it's the last night in town, and so we decided to go to Pinnacle Peak Patio; the resturant may have opened to the public in 1957 (per its website last updated 2007), but their display cabinets show postcards and envelopes from WWII simply addressed to 'John Doe; Pinacle Peak; Phoenix'. The waitress, proud of her new leather belt, and 'new in town' still bearing a California accent, came to the table. Once we indicated we had been eating there for nearly 20 years, she blurted out that the place is 'to close next March, or mebbe a year later as the developer "gave an extension"' before it is to be knocked down for yet another 'resort community' near Troon. She had heard about those other places, 'though. Seeing my reaction, she offered that 'perhaps they'll rebuild inside the new facility, but it will probably look like all the other chain restaurants'. Yeah, probably.

Well, at least a pack of coyotes woke me up at 2 in the morning, midweek, delighting at the moon; the red rocks watched silently as they have forever, and with any luck will continue to do.

... and then there were none

(full size)

When the Nazis came for the communists,
I remained silent;
I was not a communist.

When they locked up the social democrats,
I remained silent;
I was not a social democrat.

When they came for the trade unionists,
I did not speak out;
I was not a trade unionist.

When they came for the Jews,
I remained silent;
I was not a Jew.

When they came for me,
there was no one left to speak out.
-- Pastor Martin Niemöller (1892–1984)

We had a truck strike the power pole for the building hit last week; it took out the transformer with a most satisfying 'pop'. It also had the secondary effect of a power surge, which caused a 'fried' monitor, so that I had occasion to need a new one to get us back up to full complement.

New monitors offer an occasion to play 'monkey move up,' it is my turn for the upgrade, and the $200 price point has a nice Westinghouse L2210NW panel display [1680 x 1050 pixels, 22" diagonal] at the moment. I have had a Westinghouse LTV 19W3 [1440 x 1050, 19"] which I have enjoyed using since January 2006, and it seemed to make sense to stay in the brand. (I bought the 3 year service plan on that one for an extra 25% on the price, as I was unsure as to durability of this, by first panel, but that has never been needed)

One trial and tribulation (and geeky challenge) of a new resolution is the need to adjust the video card driver to support the new Modeline, and to squeeze every ounce of performance out of the monitor. I am an old hand with the Intel Modeline tool, 810resolution, and its successor, 915resolution, for my present X desktop chassis' video card.

Over time, 'progress' has removed the tools for a 'nix admin to configure a display for the X window manager:

• Xconfigurator
• xf86setup
• a working X -configure
• kudzu
• system-configure-display
• manual configuration of /etc/X11/xorg.conf

I find that the new panel has consumed 6 hours of setup time at this point, and is still not working, edge to edge at full resolution. Unpleasantly I was surprised to find kudzu erroring and dying; ddcprobe --raw returns nothing; X -configure and system-config-display seem to know only how to turn the screen blank and lock up the keyboard so that a power cycle is needed to regain the unit (I'll write more on this later); and manual edits of xorg.conf have so far succeeded in getting only an off center, mis-sized image up.

This is not at the magnitude of the atrocities of which Niemöller wrote so well; I see the battle raging about making a gratuitous change to VT's over on the Fedora-devel mailing list with false statistics abounding, and the usual 'don't bother us with the facts, kid; our mind is made up' on knowing what you need and want.

Dax Kelson wrote well with diagnosis and action plan, but it seems to have fallen on deaf ears; 'pearls before swine', and 'the tragedy of the commons' again. We must fight the good fight anyway for

"The punishment of wise men who refuse to take part in the affairs of government is to live under the government of unwise men"

-- Plato

Summary, for those still listening: I want fallback (and degraded but partial performance) modes when a tool is not working as determined by the person looking at it; I want diversity rather than monoculture in tools; I want a upstream community which does not 'break expectation' by 'feeping creaturism' (or 'creeping featurism').

I'll take a stroll to Stauf's (the coffee shop down the street) to lower my blood pressure.

stopping the next ssh leapfrog chained attack

For want of a nail the shoe was lost,
for want of a shoe the horse was lost,
for want of a horse the knight was lost,
for want of a knight the battle was lost.
So it was a kingdom was lost - all for want of a nail.

It is sensible to assume that the 'black hat' side is just a smart as the 'defense', indeed that they read the open literature and mailing lists, and think about where unseen holes might remain. They share and collaborate, albeit covertly and imperfectly.

The end case of this train of thought is that using a 'security through obscurity' approach is simply to 'hide and hope', ostrich-like, that the counter-party chooses another target.

So we end up with the case for openly discussed and developed security. It may not be possible to 'wash the linen' publicly at first, but if a project does not provide a frank and open 'root cause analysis' and response to its clientele, when an exploit has occurred, one has to question why one should trust them prospectively.

Part of basic system administration is inventorying the hosts under management. Based on review of some found cracker scripts, it is clear that some scripts 'phone home' information about the target or compromised host. At first, generic drop box accounts might have been used for transport, but of course those have to be retrieved, or forward along information, and as such can be traced in some cases. Game over.

So methods to anonymously place, and retrieve content emerge on the 'cracker' side:

• encrypted IRC networks for command, control and transport;
  
• computer mediated one-time pads and drop boxes which enforce proper use and are provable secure (at pg. 5), see also Schneier on the topic [we differ from his assertion that OTP are: 'also pretty much useless. Because the key has to be as long as the message, it doesn't solve the security problem.' While correct so far as it goes, that objection merely clarifies the remaining problem to solve];
  
• strong asymmetric [public, private keypair] cryptography with DH key transfer can permit truly untraceable secure communication.

The three preceding forms of root level access are taken from the news.

• for convenience, backups are customarily not strongly keyed with one time keys -- backup processes are customarily scheduled to run in slack activity periods, and so run at night when no-one is there to provide the keying; automated hardware one time keying systems that meet FIPS 140-2 standards are hard to do properly and expensive when certified to NIST standard levels
  
• locking bolts to control chassis access (the 'Kensington cable' chassis frame slot), BIOS lockdown, and tamper switch audit are routinely left unused and unmonitored
• the 'minimal' case of 'cracker' compromise

Presently Red Hat derived distributions carry too much gratuitous 'plain-text treasure' for a person in possession of an unencrypted backup, or with unchecked physical access to hardware, or who has root level read access.

I am thinking here particularly of harvesting 'known_hosts' and residual 'known_hosts2' for cleartext 'next hop' targets. I have speculated on this vector in the past.

Quick test to play along: run:
sudo find / -name 'known_hosts*' -print 2> /dev/null | grep [s2]$
and then as a non-privileged user, cat a few files. For extra credit and extra heartburn, repeat the inventory thus:
sudo find / -type d -name '*gnupg' -print 2> /dev/null

I certainly do not like what I see on my systems in reviewing the contents of the found files. It is clear that my practice (before authoring this piece) of rsyncing disk-to-disk backups around without cleaning up; and leaving working files on host transfers and migrations around are not well thought out as to security implication.

[herrold@centos-5 ~]$ wc /tmp/transferiso/1/root/.ssh/known_hosts
54 162 13967 /tmp/transferiso/1/root/.ssh/known_hosts
[herrold@centos-5 ~]$

Enough. I will not continue such a state of affairs. The default global ssh and sshd settings need to be altered in /etc/ssh/

man ssh_config provides:

HashKnownHosts
Indicates that ssh should hash host names and addresses when they are added to ~/.ssh/known_hosts. These hashed names may be used normally by ssh and sshd, but they do not reveal identifying information should the file’s contents be disclosed. The default is “no”. Note that hashing of names and addresses will not be retrospectively applied to existing known hosts files, but these may be manually hashed using ssh-keygen(1).

and the tool for a system-wide cleanup and conversion is in the default open-ssh already:

man ssh-keygen contains the following option:

-H Hash a known_hosts file. This replaces all hostnames and addresses with hashed representations within the specified file; the original content is moved to a file with a .old suffix. These hashes may be used normally by ssh and sshd, but they do not reveal identifying information should the file’s contents be disclosed. This option will not modify existing hashed hostnames and is therefore safe to use on files that mix hashed and non-hashed names.

We just need to have the will and the time to make the changes, write the scripts, do the work to secure content, adopt better habits, and push those habits into scripted repetitive tasks. Yeah -- that's all ... hmmm

---

081023 typo, layout, and grammar fix

If I have seen further ...

"If I have seen further, it is by standing on the shoulders of giants."

-- Isaac Newton

---

Jon Postel
August 6, 1943 - October 16, 1998

Jon Postel served as editor of the RFC series from April 7, 1969 (its inception) until his death in October 1998. Full details of the debt we all have are outlined in the eulogy by Vint Cerf.

He died a decade ago, now -- we are poorer without him.