Thursday, May 7, 2015

A forced marriage?

With apologies for a rambling rant, it's been awhile since I've written on a security-related topic.  Mebbe 'cause it'd mostly been an exercise in frustration (don't expect this post to be any different, please)...

ITWire has an article entitled "Microsoft's new secure boot strategy will suit Linux firms"[1].  The author describes Microsoft's strong-arming (my opinion) the hardware community into implementing yet-another-ineffective fix from Redmond.  Doesn't anyone remember the claims that ASLR and DEP were supposed to solve everything?  What happened there? (Hint: I'm pointing out that there's an arms race.)

This latest appears to be an attempt to add DRM to the hardware, making it impossible to use any OS other than those from companies[2] that can afford the costs of repeated code signing after each update (it's interesting who gets that money). If this latest effort goes into effect, I think the only option appears to be: give in and announce the death of the general purpose computer (as it will no longer be "general purpose").

What really spins me up about the article's discussion of the idea that this course of action is "best for everyone involved".  The thought that I can't get past is: I'd thought that arranged marriages[4] died out somewhere in the last century.  By removing autonomy (user choice), MS is only guaranteeing that a greater number of people will be frustrated with given (limited) offerings.  I guess we'll just have to "learn to love the one we're with" (with apologies to Mr. Stills for the paraphrasing).

One of the limitations involved will be the forced reliance on systems with ever-increasing complexity.  It's quite frustrating to read the articles where discussion is on a theoretical-only level.  What engineering seems to forget that the more complex a system is, the more byzantine a failure will be and the more likely that such a failure will occur[5].  By increasing complexity, the gap between theory and implementation widens[6] and the likelihood of undesired synchronicity between "small problems" increases.

Overall, the article was good, if you can ignore the last few paragraphs.  The author seems to have forgotten that the "Linux companies" exist because of their communities, not the other way around[7].  Of course, "Linux companies" will be reluctant to make comment on another company's actions as it will likely affect their own bottom line.

As part of the author-described "so-called Linux community", I'm a bit frustrated with him, having ranted on this topic and having listened to other's dire concerns.  The author seems to be a non-participant in any "Linux community" and resorts to cheap shots from the outside[8][9].  It raises concerns over who he considers to not be part of "the community[10]".

[2] Note: I'm writing this post on an OS that is not part of the group listed in the article.  First thing I did when I bought the workstation was to replace the hard drive and turn off UEFI.  I've written a number of tools for my own use and compile most other tools from source.
[3] Recommended reading: How Complex Systems Fail. [4]
[4]  The discussion of physical disabilities being a factor seems appropo to the article's premise (i.e., forcing/limiting/removing choice).
[5] An information security paradigm, relating to failure/compromise: "Not if, but when."
[6] Keep in mind that programs _still_ are rated in errors/KLOCs.
[7] Linux is written by "the community".  This means that responses tend to be numerous and varied.  It's rate that a single countermeasure will be universal across all flavors of Linux (things have to "seriously bad" for that sort of thing to happen).
[8] Re: the author's closing "lack of backbone" statement.  I see that as a sign of a community refusing to stoop to the same toxic tactics employed by it's opposition (points for remembering which company called the other "a cancer"!).
[9] I'm also wary of any author whose primary set of references is his own content.  The article contains 11 links, 7 of which point to other of the author's content.  Of the remaining 4, three point to the Linux websites and one points to someone else's article which only describes
[10] Just because you say there was no response, doesn't make it true...   From 2011: