Monday, July 13, 2009

Privilege

It's good to be the king.

The king has privilege: he is allowed to do things prohibited to normal mortals.

Operating systems have privilege levels, too. While everything that runs on the computer is a program, not all programs are created equal. The Operating System will have access that most programs will not.

It has to. Most programs can't directly access the hard disk, causing the disk heads to seek to particular cylinders. The Operating System has to do this. It has a level of privileged access denied to normal programs.

That's the general introduction. To understand security, you need to understand some details, because that's where the devils hide. The Bad Guys, of course, want privileged access: you don't become Hacker Jesus by writing a program that can't do anything.

Different Operating Systems handle privilege differently. This is where Holy Wars come from, and there's never been a security Holy War like the Windows vs. Unix one.

Unix
is old - very old, from a computing perspective, dating back to 1969 or so. It was in many ways based on concepts pioneered on an even earlier Operating System, Multics. Multics was perhaps the first of the so-called "secure" Operating Systems, and I remember that there were still a bunch of Control Data Corporation Cyber machines running Multics at Three Letter Intelligence Agency back when I was a wee lad. The name Unix, in fact, is a play on the word "Multics".

For our purposes, Linux is effectively a Unix derivative, although the details are a story in themselves - but a story for another day, so please don't post a comment along the lines of "Stallman says that it's 'GNU/Linux'". Really.

Key to understanding the Unix security model is the philosophy that programs are small, and do one (or a few) thing well. Also, the principle of "least privilege" - giving a program the lowest access level that lets it get its job done - while sometimes honored more in the breach, is still a major part of the Unix Lore. Kernels (the core of the OS) tend to be small, programs don't typically run with root (the highest) privilege, and so exploitable bugs that do major damage are (in theory) minimized.

Since the working assumption was that many users would be simultaneously using a Unix machine, this meant that it was hard for any user (other than root, of course) to do much or any damage to any other user, or to the system itself. Sure, you could write a lousy program that blew up and wiped out your data ("Don't Do That, Then" - another unixism), but your program simply wouldn't have privilege to access other user's data, or the Operating System. It might want to, but it wasn't the king, so to speak.

This is not to say that Unix is without security problems. It has a long history of hacks, and even the first known worm. Unix also has a not very friendly history of user unfriendliness - the term RTFM (Read The Friendly Manual) is absolutely a unixism.

Windows came from a very, very different background - ultimately going back to the PC/MS-DOS days of the Personal Computer. Windows 3.1 was essentially a graphical overlay built on top of DOS, and while Windows 95 had multi-user and multi-tasking plumbing built in, it was essentially designed with a single user in mind. This is the major difference between Windows and Unix: Windows didn't have the concept of a "root" user until late in its development life.

Sure, Windows NT was built from the ground up to be multi-user/multi-tasking, with different privilege levels - in fact, it was built by many of the programmers who created Digital Equipment Corporation's VMS Operating System. In a lot of ways, it has nicer security features than Unix: its audit logging is a lot more informative than Unix, typically, and there are all sorts of cool privilege levels like Act as backup.

Part of that VMS heritage, however, was a faith in interfaces - APIs - that were used to let programs access things. While Unix tended to have many small programs that did one (or a few) thing well, VMS (and NT) would have fewer, larger programs that did a number of things. Not only did this make programs harder to debug (more code = more complexity), but the interfaces let you get to several functions through the same API. The result is that with Windows if you want to share your printer, you also have to share your hard disk - it's the same API. A Unix guy would give you two programs: a print daemon that groked remote printing, and nfs, which let you share files. You could do one, or both, or neither; in Windows you can either do none (ooh - not friendly!) or both (ooh - friendly!).

Windows NT was the core on which Windows 2000, and XP, and Vista, and the rest were built. This was A Really Bad Thing for security, when it was deployed to desktop computers (instead of servers), because keeping up with patches was now ten or twenty times harder - end users were now running a server-class operating system, but the users didn't know how (or were motivated) to patch it.

Worse, even with all the nice VMS-ish security features, the assumption was still that the computer would only have a single user. Even more, that user was the one who would install new software (most Unix software was installed by an IT guru, the system administrator). And this is where we hit the fundamental religeous schism between Unix and Windows:

Windows programs expect to run with system-level privilege, because that's the only way to make sure that they install reliably.

Consider Joe Bloggs, a typical Windows user. He's not an IT guru, he just wants his card game to run. If the game software tries to install somewhere that Joe doesn't have privilege, it may or may not work. It may entirely fail (the easy troubleshooting case), or it may fail in weird ways (say, the help doesn't work). This raises the cost of the game company's technical support, so they come up with an easy solution: Install the software using Administrator privilege. Everything installs, so the number of support calls goes down.

This means that almost all companies let their users run as Administrator, because users have been installing their own software for decades, and IT thinks (rightly) that they'll lose the battle if they try to prohibit it. But now if the card game blows up, it can take the whole system with it. It's running as King.

Unix guys twitch at this, or chortle when you see things like this. Why on earth should the system crash if the graphic display system fails? A Unix guy would say that the GDI should be able to be restarted without taking the system down.

A Windows guy would say that the GDI is part of the OS, and c'est la guerre.

And now consider Bill Gate's famous statement that Internet Explorer was a fundamental and irremovable part of the Operating System, and the Bad Guys start to salivate.

From a security perspective, Windows simply exposes more privileged code to attack than Unix does. A lot more.

As security guru Gene Spafford said, "Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted."

Today we've seen why this is A Bad Thing; tomorrow we'll look at how the Bad Guys use this against us. Then we'll look at what you can do.

UPDATE 13 July 2009 20:40: Added the quote from Spaf.

3 comments:

Albert A Rasch said...

Bore Patch,

Great explanation! Even I understand it.

Albert

Borepatch said...

Albert, thanks. And thanks for the idea in the first place.

Anonymous said...

I agree, this is the 100-level stuff everyone should see before they consider using windows for anything important.

Jim