Separating Functions makes Desktops Safer

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

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

In fairness, I should point out that the Sony BMG software in questiondoesn'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, itdoesn't appear to be the case that the software was planted maliciously.There's no shortage of bad judgment, arrogance, and so on, but malicestill would be a stretch.

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

What Sony BMG's ill-fated copy protection software did was expose, yetagain, the weak underbelly of so many of today's popular desktopoperating systems. Behind that user-friendly graphical interface lies anenormous architectural flaw. (Well, to be fair, the flaw is really in theway our systems are usually configured -- albeit using the defaultsettings 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 asinstall it, all from your normal user account? It is painfully common tofind desktop user accounts with system-level privileges. That's in directconflict with one of Salzer and Schroeder's classic principles: leastprivilege.

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

Having general purpose desktop accounts that can run and install softwareis an inherently dangerous practice that will inevitably lead tore-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 installsoftware, 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 thehistorical mainframe operating systems and consider separating thefunctions of software installation and software execution.

As in most mainframe operating systems, we'd have an administrativeaccount for software installations and lock down user accounts so theycan only run software. And, unlike most mainframe environments, it wouldeven be OK, at least in many cases, for the users to have access to bothworlds.

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

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

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

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

Bye bye, Sony BMG rootkit and the like.

And of course, the success of a plan like this would rest on the softwareinstallation practices themselves. That is, preventing malware fromgetting into the system while the user is running software would only beeffective if the software gets installed carefully, following soundpractices. I'm not unrealistic about what it would take to accomplishthis. 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 desktopoperating systems would be safer places if we did a much better job atseparating the functions of software installation and software execution.

JOIN THE DISCUSSION

Loading Comments...