Non-Slacker Friday--While Stupid and Lazy

This morning I woke up with a room-temperature IQ. Heh, it happens to the best of us, so it certainly happens to me as well. Luckily I've also been incredibly lazy all morning, which has (hopefully) prevented me from energetically doing stupid things. This has nothing to do with Friday, per se, as I have no traditional fixed schedule in which a Monday through Friday work week is followed by a weekend. Like everyone else in IT I am, for better or worse, interrupt-driven. This is hardly limited to security workers.

So, that whole waking-up-stupid-and-lazy thing is more in the nature of something that just happens now and then; I form no hypothesis as to why. Still, there are a couple of things I can write up that (again, hopefully) do not require a great deal of thought. Both are related to community service, which of course take many forms, from the purely physical, such as my telling a neighbor yesterday that there was a family of river otters (two adults, three kits) playing in the Willamette River behind casa de Greg (great fun to watch—search YouTube if you doubt it) to the virtual or professional.

Upon those River Otters hangs both a tail (I thought they might be beavers until I saw one) and a tale. The tale is about virtual and/or professional communities, databases, SELinux, and how I came to see them. It goes like this.

Very early Wednesday morning, I had a rare summer power outage. Given the timing, and the number of sirens I heard a short time later, it seems likely that someone hit a power pole. This wasn't an immediate problem, as I was on a Linux workstation protected by an APC UPC. Calibration data and a bit of testing led me to expect between 30 and 40 minutes of life, under reasonable loading, to save work, write whatever notes were required to maintain mental state, and do a clean shutdown if necessary. Given my power-pole hypothesis, this seemed likely, and I could track UPS state as remaining time faded via a trivial bash script.

$ cat apcrpt

#!/bin/bash

# apcrpt: Quick look at the APC UPS.

date

apcaccess | egrep "(STATUS|LOADPCT|TIMELEFT)"

Here is a sample run, taken a moment ago, under a very light load:

$ apcrpt

Fri Aug 22 10:45:24 PDT 2014

STATUS : ONLINE

LOADPCT : 8.0 Percent

TIMELEFT : 89.5 Minutes

$

When I became uncomfortable with remaining time I shut the system down, and walked down to the river. Hence River Otters and, as luck would have it, turning an annoyance into a Very Cool Thing.

Note the disparity in that moments-ago look at TIMELEFT and what I usually anticipate. It comes down to this workstation usually having a database server running when I am working, with databases being of varying criticality, from the completely trivial to recreate, to a couple of others which are somewhat to vastly more more likely to cause me potentially large problems in the event of data corruption.

It is those more critical databases which prevent me from running the db server at all times, even though there are ample system resources to do it, and it would be most convenient. See https://bugzilla.redhat.com/show_bug.cgi?id=1096484.

A bug in SELinux prevents a complete and clean shutdown of both the UPS and the workstation, which is my minimum requirement. I reported this in May, and there is no fix as of yet. It seems likely to also impact UPS hardware lifetime, as it can drain batteries completely flat. Which is another reason I wish it were fixed. Absent a fix, I manually start and stop the db server, which is not an adequate work-around.

Hardware lifetime issues aside, running databases on systems with unreliable power is a recipe for potentially disastrous results, which can make hardware expenses trivial in comparison. It is somewhat ironic that so much attention has been devoted to making cluster solutions robust in the face of node failure, but seemingly very simple things can fall through the cracks. Not that I said 'seemingly'. This might be a complicated issue. Worse yet, it might be complex.

But Wait, There's More

The next SELinux bug is https://bugzilla.redhat.com/show_bug.cgi?id=1130819. It's a bit weird in that when I tried to report a bug against policycoreutils-sandbox, Red Hat Bugzilla didn't recognize this as a valid component. More experienced bug reporters have doubtless run into this problem, but how to deal with it has not made it into anything that is easy to find.

My concern was that this is about Chrome; sand-boxing Google Web browsing technology. Yes, Google has made much of sand-boxing as a native security technology. But skepticism is one of the traits of security people. First off, sand-boxing has a terrible track record. The technology is getting better, but it's not yet a reliable technology in any context, and it has to operate in a very dangerous environment—running foreign code in a sensitive environment.

It is appropriate to mention that Chrome was insecure from the day of that it launched, out of the blue, on 9/1/2008. As I reported at the time, it was based on an old and vulnerable version of WebKit, and sure enough, one day later ZDNet reported Google Chrome vulnerable to carpet-bombing flaw

http://www.zdnet.com/blog/security/google-chrome-vulnerable-to-carpet-bombing-flaw/1843. Uncritical, fannish attraction to any particular Web browser is something that really should be discussed in any modern security training program. So please do that.

There is Still More

So far, this has about contributing to the community of Linux users. That is a useful thing to do, but there are other communities, such as professional organizations, such as ACM. I am not going there today, though I mentioned it earlier. Its complicated, the implications are important, and this is already getting into the area of a thousand words. This is quite enough for a lazy day.