Separating Functions makes Desktops Safer

Download the authoritative guide: Cloud Computing 2018: Using the Cloud to Transform Your Business

Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  
Unless you've been visiting some other planet, it's more than likely you've heard or read about the so-called 'rootkit' software that was found on some copy protected Sony BMG audio CDs recently.

It used to be we only had to worry about the bad guys putting bad stuff on our computers. Now, we also need to worry about the good guys. Yes, I know spyware has been around for some time now, but this case strikes me as a particularly egregious example of good guys trying to do bad things.

In fairness, I should point out that the Sony BMG software in question doesn't appear to be the same situation as a traditional rootkit per se -- if there is such a thing as a traditional rootkit. For starters, it doesn't appear to be the case that the software was planted maliciously. There's no shortage of bad judgment, arrogance, and so on, but malice still would be a stretch.

That said, it sure did have many of the same characteristics as the rootkits that we've seen attackers use for more than a decade against our computers -- it hid its presence, was difficult to remove, and such. But that's not what I'm here to talk about.

What Sony BMG's ill-fated copy protection software did was expose, yet again, the weak underbelly of so many of today's popular desktop operating systems. Behind that user-friendly graphical interface lies an enormous architectural flaw. (Well, to be fair, the flaw is really in the way our systems are usually configured -- albeit using the default settings provided by their vendors all too often.)

Any guesses as to what this pernicious flaw is?

Consider this: On your desktop, are you able to run software, as well as install it, all from your normal user account? It is painfully common to find desktop user accounts with system-level privileges. That's in direct conflict with one of Salzer and Schroeder's classic principles: least privilege.

Sure, it's easier to give users the ability to install software on their own systems. The conventional wisdom in many IT shops is that it results in fewer help desk calls from users who demand the ability to install software. Although this may well be the case (but I'm inclined to disagree), the problem that we saw with the Sony BMG copy protection software is that the CDs in question were able to install their copy protection software when the user inserted a CD containing the code. Had that software installation failed due to insufficient privileges, the rootkit would never have been installed. Oh, and the audio CD would likely not have been played. (No good deed... )

Having general purpose desktop accounts that can run and install software is an inherently dangerous practice that will inevitably lead to re-installing your operating system when something really nasty happens. Its sheer madness, if you ask me.

I'm not advocating environments where only the IT shop can install software, although I've seen that work quite effectively more than once. What I'm saying is that we would be well served to learn from the historical mainframe operating systems and consider separating the functions of software installation and software execution.

As in most mainframe operating systems, we'd have an administrative account for software installations and lock down user accounts so they can only run software. And, unlike most mainframe environments, it would even be OK, at least in many cases, for the users to have access to both worlds.

I know what you're probably saying: Your desktop OS does exactly that by way of an administrator account and regular user accounts.

As I said earlier, the underlying operating systems, by and large, have the ability to do this right out of the box, but it's common to find that dangerously circumvented on desktop and laptop systems. In the desktop OS installations I've done during the past year or so, I've found the installation process generally drove me to give the desktop user the privileges needed to install software.

I've also found that this dual account model doesn't always work well with all software, but that's another issue.

Don't get me wrong... I'm not saying a simple mechanism like this will solve all of our security problems, but it will sure help with some of them. When done well, this mechanism includes good old file access controls that would prevent users (and the little nasties that follow them home through their browsers, emails, instant messages, etc.) from affecting the installed software base, from the OS through the legitimately installed applications.

Bye bye, Sony BMG rootkit and the like.

And of course, the success of a plan like this would rest on the software installation practices themselves. That is, preventing malware from getting into the system while the user is running software would only be effective if the software gets installed carefully, following sound practices. I'm not unrealistic about what it would take to accomplish this. It's going to be tough to get the whipped cream back into the can, as it were.

Even with these caveats in mind, I'm still convinced our desktop operating systems would be safer places if we did a much better job at separating the functions of software installation and software execution.

Submit a Comment

Loading Comments...