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.
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
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.