Non-theatrical security

As it turns out, a good friend was on that Northwest flight. I won’t identify him (though I know he reads this blog occasionally). What happened to him has made me think of my own responses in such a scenario. But it has also made me question the TSA’s kneejerk ineffective new guidelines.
Especially in light of the potential accuracy of this report, if true, suggests that real security measures ought to be taken. What the TSA proposed and implemented would not have stopped this.
Bruce Schneier, noted security guy in computing had this to say:

Read moreNon-theatrical security

What I really want to do is to disable device-mapper on install …

Sometimes … sometimes … helpful utilities are helpful. Like installation systems that present the raw hardware with drivers to me, and let ME decide what I want to do with them.
Unfortunately … I often run head first into bad choices made by the installer coders or architects. Dm-raid is one of these cases. It is very hard to disable it from a Centos install. Very hard. Pretty close to damn near impossible.
Hold it … why would we want to disable this?
Simple. I (as in ME) want to control how my disks are configured.
This isn’t a Centos issue, as they repackage RHEL. This is a RHEL issue. Device mapper is used when a fake-raid is detected … correctly or otherwise. In this case, the fake raid is incorrectly being detected. And I want to … badly … turn off the fake raid detection. Badly.
brokenmodules=dm_… don’t seem to do the job.

Read moreWhat I really want to do is to disable device-mapper on install …

The danger of controlling too much of your stack …

This is related to an issue we ran in to, today, and several other times. It sounds strange, but if you maintain rigid control over a huge swath of your stack, you run a fairly serious risk of being unable to respond to changing environments as quickly as your competition. The law of un-intended consequences bites you, fairly hard. Worse, you rarely, if ever, realize it, until it is too late.
For example. Suppose you are an iSCSI stack provider. You want to build iSCSI stacks. So you build a target and an initiator. But you decide you really want to make peoples lives simpler, by removing the complexity (read as “choices available”) in using your stack. So you decide to adopt a single platform. Time goes on, that platform that you are locked to ages, and isn’t updated as quickly (you are locked to it, but you don’t own it) as you might like. So you start falling behind in systems support.
All the while, more nimble competitors are grabbing up mind share and market share, as they are focused upon provide great tools, not a platform.
Sounds strange, but there is danger, fairly significant danger, in providing a complete solution platform.

Read moreThe danger of controlling too much of your stack …

Just too funny …

XKCD comic from a few days ago .. reminds me of the spherical horse joke I used to tell … For those not in the know, physicists like to reduce complex problems to simpler problems, solve the simpler problem … so when designing a faster race-horse, why not make the horse spherical rather than its … Read moreJust too funny …