Separating Functions makes Desktops Safer

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.