Modern Linux distributions and their innate feature creep

Ubuntu 11.04 has been released today. Why is that despite the announcement of a new and innovative user interface (Unity) and the inclusion of critical building blocks for private clouds (among others) I don’t get the excitement I used to have when a new release of a major distribution came out?

Maybe I just grew numb of the claims of revolutionary features and disruptive technologies. Or it could just be that I believe that “featurism” doesn’t equate to software quality, usability and future proofing.

I’ve been involved with Linux in one way or another for far too long now (ever since I saw the original message posted by Linus in the comp.os.minix newsgroup back in 1991), and I’ve played with every major distribution under the sun. You name it: SLS, Slackware, Yggdrasil, RedHat, SuSE, Conectiva, Mandrake, Debian, Gentoo, Ubuntu, etc., all got their fair share of the flavor of the month hardware that I had at the moment (still remember running the first few of these on a 386SX 20Mhz). And there was a time when I could literally recite from memory the complete boot process including every executable and config file, and remember the layout of the init rc system for each of these installations. There was also a time when I could quickly take a look a the kernel source code to understand certain behavior, or even fix an annoying bug.

Nowadays things have grown significantly more sophisticated. The diversity in hardware has increased by orders of magnitude, generating additional kernel complexity (and this not only affects the drivers subsystems), the multitude of commercially supported distributions striving to survive and make money compete for the latest and greatest differential feature that will allow them to see their market share increase by a slim percentage, and the overzealous competition with Microsoft forces the proliferation of capabilities that most of the end users will never need.

And the additional complexity doesn’t stop there: software engineering became increasingly more complex by adding layers of abstraction on top of layers of abstraction under the (false) pretension of “more efficient programming models”, for dubious programming productivity gains at best in many cases. I am not saying that taking away pointer arithmetic from the average developer responsibilities doesn’t help avoid common mistakes and potentially increases software reliability, but it seems that nowadays programmers can’t even code a simple quicksort without resorting to the latest and greatest class part of their favorite object oriented language toolkit library (and maybe some of those people should not call themselves programmers either, but that is beyond the point).

There is nothing inherently wrong with having options, particularly when you don’t need to pay for them (at least directly), and with squeezing a few more drops of productivity out of every programmer, but bloat comes at a price: complexity is the natural enemy of software reliability (and usability). And when I say reliability, I also mean security, code maintainability and general system stability.

Going back to the central topic of Linux distributions: what is that a Linux distribution must absolutely provide? A relatively easy way to install a stable system, a good package management system that handles package dependencies (even reverse dependencies) well,reasonable defaults, a consistent strategy to the installation of additional packages and timely updates. This is not much more than what you could get with RedHat 3.0 about 15 years ago. So how did Linux distributions spend the last 15 years?

I am not advocating throwing away what we have and installing OpenBSD (BTW, Theo, source code patches and recompilation as the official method of updating your kernel and your basic distribution in 2011 truly sucks!); what I am really saying is that we should seriously spend some time understanding what is absolutely needed and cleaning house in the major Linux distributions. Is there a reason why we need several word processors? And why is that we would want to have 2 or 3 different window managers?

And to the developers: I’m not saying that everyone should become a demoscene wizard, but thinking and coming up with an algorithm on your own once every a while, rather than gluing classes together all the time can be a quite fulfilling experience.

Opensource is based on the noble idea of diversity tolerance, but it’s also based on less altruist principles such as Darwinism and “benevolent dictatorships”. It seems to me that the Linux Kernel benevolent dictatorship works (at least to a point), but the survival of the fittest principle is definitively not working when it comes to modern Linux distributions.

 

Posted in Distributions, Linux | Tagged , , , , , | 1 Comment

This time is PSN. Who’s next?

A week after taking down PlayStation Network, Sony finally explains that it did so due to a breach. And this is no ordinary breach either. Some analysts estimate that personal information of over 75 million of Sony’s users has been exposed. What makes this incident even worse is that credit card data for a large percentage of those users could have been also compromised.

While Sony is undeniably responsible for the security of its systems and the personal information exposed, it is only fair to also put significant responsibility on the credit card industry for what could be the largest credit card compromise in history. This event is yet another sign that PCI DSS is just a bit more than patchwork around a broken process.

Who would ever think that a secret shared across hundreds or thousands of people is still a secret? Can someone believe this assumption to hold true while made subject to the prudent man rule? And yet this seems to be what the credit card industry wants to believe by establishing a process that requires a set of “secrets” (name, credit card number, expiration date and possibly cvv) to be shared among the credit card holder and every merchant and payment gateway that card is ever exposed to.

In the physical world, where you are required to present a piece of plastic (and maybe a magnetic band and possibly a photo ID) together with this information, there is at least the additional challenge of counterfeiting the credit card and driver’s license. But in the virtual world where only bits are presented and used for the verification, there is absolutely no restriction over the leak, copy and misuse of this data.

And it is not that there are no other proven methods to perform secure transactions without the need for a shared secret. Public key infrastructure ciphers such as RSA have been known and used for over 30 years to provide digital signatures and non-repudiation. And the best thing about them is that neither they need a secure channel, nor they require the exchange of any secret.

Why doesn’t the credit card industry recognize that the current payment process is badly broken when it comes to e-transactions and moves forward to using digital signatures? It is certainly not because of cost (the new process could be implemented with little more than GNU gpg, a nice wrapper GUI and a good campaign to demonstrate the value of such an approach). Users would create a key pair, the credit card industry would take care of the client certificates and the payment process would consist of digitally signing the invoice with the secret key (which, by the way, is never exposed to anyone). The verification of the signature using the client certificate (or public key) would constitute enough record of the particular transaction.

What is wrong with this picture? If this is a quantum leap over the existing broken process and is a proven method for identity verification, why isn’t the credit card industry mandating it instead of wasting time trying to build fences (a.k.a. PCI DSS 2.0) around sensitive secrets shared by hundreds or thousands of merchants?

I can think of a quick answer, but I hope it is not the reason behind it. My guess is that, by taking the merchants out of the equation, the residual risk would live with the credit card holders, their workstation security and the credit card companies themselves. This situation would make the credit card issuers liable (and not the merchants anymore). Is this too much blame to take for the credit card companies? Is it better for the credit card industry to pretend that this solution doesn’t exist and continue to blame the merchants for their insufficient security and their inability to meet the requirements of the latest and greatest PCI DSS standard?

Maybe one day in Utopia legislators and regulators will consult with true security experts and will be advised correctly. And perhaps that day they will make credit card issuers liable for their inaction. There is even a possibility that this will happen in our lifetime. Until then, we’ll need to continue to fake that nothing happened, that giving your credit card information electronically to any merchant is fine as long as they present a valid SSL certificate and that merchants are the only ones to be blamed for every case of credit card fraud.

 

 

Posted in Fraud, Information Security, PCI DSS | Tagged , , , , | Leave a comment

Hello world!

Back to the Blog-sphere from a long hiatus. It has been over 5 years and a lot has happened in technology, information security and Opensource.

I guess there is not much to say for now, other than “Hello, World!” and “It’s nice to be back!”.

Posted in General | Leave a comment