A letter to a manager about security, databases and openness
Paw Prints: Writings of the maddog
Recently I was talking to a high-ranking government official about the choice of using Free Software instead of closed-source proprietary software. In this letter I mention "Microsoft" a lot, since most people know them, and they make a wide variety of products. However, you could just as easily substitute almost any closed-source vendor and have the same message.
One of the people who was copied on the letter, thought it was worth sharing with others, so here is the letter (somewhat edited) for my blog:
Please let me apologize for not answering your questions sooner, but I have been very busy traveling, and getting time to sit down and direct a letter to specific issues is hard.
The first issue you brought was one of security, that of closed source software versus open source software.
In my opinion there is no such thing as a secure computer system, and particularly one attached to the Internet. Many of my friends in security agree with this statement, and ALL of the ones who are good at security agree with it. All you can have in this case is increasing levels of security, but you are never SECURE.
Secondly, I personally feel there is no inherent, measurable difference between the code written and kept as closed source versus the code written as open source when it comes to security "goodness". The main arguments that I have heard for and against "openness" are:
- Open Source allows hackers to see the holes, and attack them, whereas closed source obfuscates the holes, so hackers do not see them.
- Open Source allows many people to review the code and therefore find the holes before the hackers do, and fix them.
Both of these arguments have a bit of merit, but a lot of falsehood.
On the first bullet, if it was true that obscurity helps security then Microsoft's code would be the most secure on earth, and in my opinion, it is not. Likewise Linux would be the least secure on earth, and companies like Google, Ebay and others would not be able to use it.
On the second bullet, much code is released with only a few eyes looking at it, and many customers never look at the source code, so the review completeness is typically not what is claimed. On the other hand, review of closed-source code by many programmers before it is released is also rare.
The real reason why I consider FOSS code "more secure" is the fact that the only way you can maintain a secure system is by constantly looking at the log files that tell you what is going on with your system, finding people trying to exploit your network, and then fixing those exploits QUICKLY.
It is in the last area that closed-source companies fall down, and in particular with customer projects that have to last a long time.
With "modern" operating systems such as Windows 7, Microsoft will be aggressive in creating patches for their operating systems. When they detect a problem (typically reported by a customer), they will assign an engineer, study the exploit, create a binary patch, test the patch, then (depending on the severity of the exploit and number of systems having it) will determine whether they release the patch immediately, hold it for a series of system patches or hold it for an update of the operating system in general.
In the meantime the customer who reported the patch is helpless to fix it.
With FOSS, when the developers are made aware of the issue, they create a source level software patch that can then be delivered and installed by everyone. The patch is then worked into the kernel (or libraries, or utilities), and can be installed as updates, and finally delivered to the distributions so the customers never see the problem.
Now let's talk about patches to systems like XP, or Windows ME, or Windows 2000, or other operating systems that you might still be using, but which Microsoft no longer supports.
If you determined a problem with these, you would have to call Microsoft and negotiate a price for creating the patch...IF they would create a patch for you.
It would take a long time, and you might never get the patch. Microsoft might therefore FORCE you to upgrade to another system (with all of its inherent costs) just to get a security patch.
With FOSS you could either have some of your systems people study the issue and create the patch, or update just the kernel part of your system to get the fix, or hire an outside consultant to fix the problem.
In a recent article in one of your newspapers, Microsoft talked about the "accountability" of closed source vendors to customers for security issues.
Accountable how? Will Microsoft insure their customers against loss for a hacked system? Will Microsoft supply critical security patches to older software that they no longer support, but which customers are using? Did you ever read a Microsoft warranty? It does not even hold them accountable if your computer bursts into flames only because of their software. Their warranties are worthless, therefore their "accountability" is worthless. I worked for a large systems company and I know that the lawyers inside Microsoft would never let them write a warranty or enter into a contract that held them truly "accountable".
If what Microsoft is talking about is a large company who might take on tasks of fixing software bugs, then I can point to companies like Red Hat Software, SuSE, Canonical and (a small company I am sure you have heard of) IBM who would be happy to be as "accountable" with FOSS as Microsoft is with their closed source code.
Microsoft's representative says that the government does not have the expertise that "comes with the challenges of Free and Open Source Software". Whether that is true or not, if you continue to develop solutions using only closed source, you will never develop that expertise.
Finally, I will point out that in my experience with security issues it is NOT the issue of whether the code is open or closed (other than the “quick to patch" issue), but:
- the philosophy of the development of the operating system
- the end users and systems administrators and their training
On the first bullet, Microsoft Windows was developed as a single-user, non-networked operating system. Early versions of the operating system had no protection of the kernel from the applications. You did not even "log on" to your system...you simply started it up. Even when Microsoft Windows finally was networked, emails that had attachments automatically opened, which might have allowed viruses to attack the system.
Unix and Linux systems were "always" designed to be multi-user and networked. They took a different security model, that of "no trust". This one reason why the National Security Agency (NSA) of the United States chose Linux to create their "Security Enhanced Linux" (SE/Linux) project, so as to create a really secure system.
Linux has two different security models (SE/Linux and AppArmor) to chose from. Each has their own advantages. Linux also supports Kerberos, a network security system invented by MIT.
The second bullet is the most important. End users are very hard to train in security issues. Unix and Linux systems have taken the "no trust" model to force end users to be more secure with how they use their systems. While I am not an expert on Microsoft security, they tend to allow less secure systems due to wanting compatibility with past software.
You also asked about "Databases", and I am less sure what you wanted in this area. I am not an expert in databases, even though I taught database design and structures twenty years ago.
Most of the common commercial databases, including Oracle, work and are supported on one Linux distribution or another. You can purchase them and support from the respective companies.
If you go to this page at SourceForge.net:
You will see approximately nine pages of database entries, strictly for the different engines and how to access them.
The main FOSS engines are:
- Berkeley DB
- Couch DB
each has its own followers and things it does well, but there are a variety of others.
All of these databases can handle very large amounts of data. Firebird was once a commercial product only, and was completely compatible with Digital Equipment Corporation's RDB database, which sold for thousands of dollars per machine (and that was when a thousand dollars was a lot of money).
Again, the secret to good database performance is knowledge of the database, how you formulate your records, etc. and is not an indication of whether you should be using a closed-source database versus an open-source database.
However, with the open-source database you can save money on the license and put that money into additional training and support costs.
Microsoft and Open Source
Finally, I have been made aware of the claim of Microsoft that "they support open source". Microsoft supports open source like I support farmers. I need farmers to provide me with the food so I can stay alive, but that does not mean that I actively go out and help them plow.
Microsoft's contributions as a company have been to projects in making sure that those popular FOSS projects like PHP and Apache run on their closed-source operating systems. If these projects did not run well, then Microsoft's operating systems would be even less useful.
As to their contributions to the Linux kernel, most of these were in the areas of Virtualization, to allow Microsoft operating systems to useful on top of a Linux Server in a virtualized environment. Again, they are strictly to keep Microsoft viable in the enterprise, not that Microsoft "embraces Free Software".
I will also say that individual employees of Microsoft ARE contributors to FOSS projects, but these are mostly volunteers, and have nothing to do with Microsoft's business strategy or love of FOSS as a company.
Microsoft's "Focus on Interoperability" has some strange illustrations, such as the time that Microsoft changed their JAVA implementation so it was incompatible with the others, or the time they changed Kerberos so it was incompatible with Kerberos from MIT (the one that every other operating system uses), or the fight they had to try an knock out ODF as a data format and have OOXML (their "standard") in its place...fortunately losing on the last example.
I hope that this email helps answer some of your questions.
Simplify, simplify...I fully agree with your comment regarding encryption of the PROM. Once again this is a trade off between transparency and security. I also agree that the physical control of updates to such a PROM is a good idea.
I have spent most of my professional lifetime exploring and explaining the various potential and realized uses of computers in medicine. I now find myself on the sidelines of my profession, and, having read an article about how the so-called US medical system really functions, (Time Magazine, current issue, take 2 anti-emetic pills before reading) I should be happy that I am no longer actively engaged in it. As I suspect is the case with most physicians, I was subliminally aware of how the mindless pursuit of money and perceived power had distorted medical care in the US. Now that the fundamental corruption of this system is laid bare, I am appalled. (This also explains in part why I sit on the bench these days--when I was practicing, I was attempting to push 'the system' to do what was right, by limiting the use of Xrays and CT scans to those situations where they were, in my opinion, truly warranted; at the same time I was vigorous protesting the misuse and abuse of IT by Community Health Systems, who no doubt wanted me silenced (suffice it to say that the IT at their hospitals is so bad as to represent a serious patient safety risk).) My colleagues recognized my efforts by electing me to 'Best Doctors of America' in 2010 and 2011 (just before I was forced out). Apparently an honest physician is considered a liability these days. O tempora, o mores.... The author's prescription for addressing this mess? TRANSPARENCY. (Now where have I heard this before...something about open source software, maybe?!!?)
Waiting for my next adventure to show up gives me a lot of time to think about all sorts of things, as well as to return to my roots as a jackleg audio engineer. (I have developed an amazingly simple and accurate headphone amplifier design that I have been building into prototypes, including an inexpensive Chinese built MP3 decoder player module, which together I call an 'A-pod'--a music player for adults.I think I will construct these for fun and offer them on Etsy or E--bay. But I digress.)
One of the subjects I obsess about these days is user interfaces. This has become a very hot topic in the FOSS domain (ie the constant fuss about GNOME vs. KDE vs. UNITY vs. (gack) MS Windows and Macintosh on the closed (dark) side. Though everyone else seems to think that the Xerox PARC derived WIMP (Windows, Icons, Mouse, Pointer, also What Idiots Made Prevalent, Waste In Monumental Proportions, insert your favorite acronym here) human interface represents a step forward from keyboard input to a command line (CLI for command line interface, clods like it, computing lunacy and idiocy, etc etc--it is great fun to abuse the common acronym!). In the name of utility, we have created enormously large and complicated software artifacts which gobble machine cycles by the quintillion (I exaggerate but only slightly). Would not a modified text based interface work as well, with less compexity? (The current WIMP interfaces benefit greatly from being open source (those that are) since software this complex needs a whole bunch of eyeballs to make its bugs ahallow (Jones' restatement of Torvalds' Famous Observation).)
I believe in the final (or so far as I have gotten to date) analyis, computer users seek to follow a path through software, stringing together individual tasks to accomplish a series of objectives. Putting a naive end user in front of a WIMP interface says, in effect, "Here is a list of activities, choose where you want to start (if you dare), then choose where you want to go next from there, and by the way, ROTSA RUCK! I believe the extent of computer literacy among today's humans is a testament to their underappreciated (and greatly underestimated, even among congresspeople) sheer intelligence. My comments about what an audomobile would look like if designed by FOSS engineers have been published elsewhere. (Out of sheer kindness, I did not elaborate in that screed on what an automobile designed by Microsoft would look like, let alone how well it would work.At least the FOSS model would transport you reliably.) I believe a closer look at simplifying softwre user interfaces would be valuable,and I hope you will commend this to various of your friends and acquaintances who have the skills that I currently lack to build and test such software. I am regathering programming ability, but it is going slower than I would like, maybe my neurons are getting too old and tired for this stuff (but I devoutly hope NOT).
I still think that some sort of 'uber language' like the proposed NUBOL might be of value, functioning like those encapsulated subunits of LEGO that make it possible for children to build space station look alikes.
UML was a worthy beginning effort in this vein, maybe the world is ready for NUML?
PS If you know anybody who could use a radiologist/computer wizard/audio engineer/musician/cat lover in their enterprise, please inform them of my availability. Even thinking deep (?) thoughts, petting cats, building audio equipment and hearing new details in old recordings grows tiring eventually, and I would love to make a greater contrtibution...somewhere...prefereably soon. Like Bilbo Baggins, I think I have a few adventures left in me.
PPS I admire your courage in subjecting your sexual identity to transparency. It is right to honor Alan Turing (who did as much to defeat Hitlerism as any general or poliitician) and to condemn the criminal mistreatment of Turing that destroyed him and robbed humanity of the fruits of his genius. I am myself a suppressed heterosexual (for the past 15 years, I have taken enough Sertraline to desex a raging bull elephant, for treatment of familial depression--no depression but no sexual interest, either--a reasonable and in my case lifesaving trade off in my opionion). So I guess that makes me a sexual nullophile. I vehemently pray that you suffer not the slightest ill effect from this revelation, which I consider truly irrelevant to your considerable worth as a software engineer, WOOF (Wise Outspoken Old Fart--a perfect acronym for a Maddog), and human being.
Encrypted Proms and New Computer LanguagesFirst of all, let me thank you for a very thoughtful and well-crafted comment.
On the part about the "encrypted PROM", there is a part that go against the grain of what I am saying. I think that having something closed (and the encryption makes it, for all intended purposes, closed) does not ensure greater security. From my personal experience, having something open, with the code visible, allows others to review and more easily fix it when an exploit is found.
I would suggest that your "PROM" be programmable when a jumper is moved on the motherboard. The concept of "possession being nine-tenths of the law" and the fact that the motherboard would have to be in physical possession of the programmer to have the code changed would go a long way to security.
Of course the addition of this PROM and jumper would cost money, which is what most people do not want to pay....
On the part of the simpler language: There have been many "simple languages" over the years. My feeling is that it is not the difficulty of the language itself as to what the language allows. Cobol, for instance, had not concept of "pointers" and what they meant. The complexity comes from trying to make a very dumb machine do things in a fast and "smart" way.
I do not think that everyone needs to be a systems programmer, any more than everyone has to be a doctor. I do believe that it is good for people to have a rough understanding of how much work it takes to write a program that will direct a computer to do something, just as it is a good idea to train people to clean a wound and apply a bandaid, then understand the rough difference between this task and brain surgery.
Hardware, Software and SecurityDear Mr. Dog:
(Forgive me, I love plays on words, and this salutation has tickled my fancy ever since I learned of your, ahem, unique, if highly inappropriate (you are clearly 'crazy like a fox') nickname.)
Your comparison of end user experience with Microsoft Windows and Linux speaks for itself, demonstrating how open source technique, if properly applied, is more effective than closed source in preventing exploits.
Ultimately, computer system (ab)use is a channeling of power--that added to human capabilities by computing artifacts. Exploits seek to direct that power to uses unintended by the artifacts' owners, often to the dismay and detriment of said owners, not to mention human society in general. (I allude to Al Quaeda's abuse of aircraft technology on 9/11/01 as a similar example.) As you point out, the only sure way to avoid such abuse is to totally isolate the artifact, denying its benefits to potential end users. There is always a trade off between utility and security, and balancing this assures perpetual employment to talented, wise, and dedicated systems operators and engineers (as well as sleepless nights to those who depend on technology (and especially that subset of dependents who have not been educated enough to understand it).
I also observe (since this is too often ignored in these discussions) that source code is only open to those who 'speak' its language, and, also depends on the quality of the documentation that accompanies (or all too often fails to accompany) the code. In reading code (I am currently trying to become literate in various dialects of C++), I am struck by how difficult it sometimes is for me to understand it, despite my many (over 50) years of computer addiction (fascination, besottedness, insert favorite expression of unreasoning overdevotion here).
It may be time to devise a computer language that seeks to be understandable to non-geeks--a new form of COBOL like langauge--I propose the name NUBOL) so that less computer educated people can get a grip on what is actually going on inside our favorite black, blue, grey and off white boxes. (I exclude the garishly colored boxes favored by computer gamers, since very few (especially not the gamers, that would eliminate all the FUN) would wish to know what is going on inside THEM.)
I also observe that there are ways to improve software security that have been employed in the past and perhaps deserve another look. Encapsulating system software in encrypted PROM (reprogrammable only by technicians in possession of a secure key) might be useful, especially for the most security sensitive applications. This is an extension of the signed UEFI technology that is entering common use at present (and which Microsoft is attempting to misuse to avoid having to compete with LINUX). Isolating inter-computer communication in its own dedicated computer (easily done at Raspberry Pi like expense) at the hardware level is yet another. (This can and is being done using virtualization and sandboxing at present, but at the expense of taxing overall system operation.)
My final observation (this should amuse Professor Stallman and his adherents) is that closed source software is indeed a form of taxation (the end user pays the price of purchase AND the price of ignorance of what the program is actually doing) without representation (the vendor only obliquely, if at all, asks the end user if the software meets expressed needs). This of course equals TYRANNY, which we mostly agree is to be avoided if at all possible. Enough said.
Linux Foundation's big event celebrates the 25th anniversary of Linux
Competitors get in the game with RHEL without Red Hat
Security researchers have already notified Microsoft; some fixes are available
The company is collaborating with Google and Intel to use Kubernetes as an engine for Fuel
Customers can take a free test drive of SLES for HPC on the Azure Cloud
San Francisco-based chip company announces their first fully open source chip platform.
The whole distro gets rebuilt on glibc 2.3
Ubuntu Vendor tries to solve app packaging and distribution problem across distributions.