Reducing Service Privileges


How Vista Toughens Services: Overview

You've already read why security analysts worry about services: they're programs that are on all of the time, are often network connected, and often run as LocalSystem. That typically leads security analysts to recommend several things:

  • Shut off any unnecessary services. Vista's done this to an extent, and as time goes on we'll probably see more and more advice about what we can turn off safely as we all become more familiar with Vista.

  • Replace the LocalSystem account with a lower-power account. That way, if a service is compromised then the attacker only has the power of the lower-power account, and may not be able to do as much damage. XP started this by introducing and exploiting the vastly reduced-power accounts NetworkService and LocalService. But where XP used them for a relatively small percentage of services, leaving most to LocalSystem, Microsoft has reengineered many services under Vista so that they run by default under LocalService or NetworkService.

  • Use permissions to deny LocalSystem, LocalService, and NetworkService access to particularly valuable files, folders, or the like. For example, when Code Red hit unpatched IIS servers across the world back in 2000, I must sheepishly admit that my IIS server was hit because I'd not patched it, but I was largely unaffected because I had previously denied the LocalSystem account access to my Web content. When Code Red tried to delete my home page, then Code Red spoke with the authority of LocalSystembut was rebuffed by its lack of NTFS permissions to even read it. Taking the time to deny service account access to some objects (Registry keys, files, other services, AD objects, and so on) can be a good belt-and-suspenders exercise, but a time-consuming one.

Those last two approaches together comprise a notion called "running with least privilege." The idea is that in the perfect world, every service would run under an account specially built for it that had exactly as much power as it neededand no more. And, in an even better world (I know, what's better than perfect?), we'd take things a step further and actually explicitly deny those least privilege accounts access to anything that they didn't need.

It's a great idea, but hasn't been practical as it was time consuming and not always fruitful. But Vista incorporates a few changes that offer simpler paths toward running with least privilege and service hardening. Those changes are:

Session separation Vista largely blocks services from directly interacting with users. As you'll see later, Microsoft created something like a completely separate Terminal Services session and stuck the services in there. You needn't do anything to get this benefit, it's automatic.

Reducing service privileges Under Vista, you (or the service's developer) can tell the SCM to continue to run a service as LocalSystem, but to strip the svchost's token of any of LocalSystem's unnecessary privileges. The result is that SCM can essentially convert the frighteningly powerful LocalSystem into a tailor-made service account of least privilege! Again, this requires a bit of setup work on either the developer's part or the admin's, but many Vista services appear to have already had that work done for us. (I'll show you how you can view a service's privilege limitations with the sc qprivs command and add new ones with the sc privs command a bit later.)

Service isolation You just read that in the perfect world, a given service could access just the files that it needed, and no others. With Vista, you (or a service's developer) can accomplish that very thing with just a few simple adjustments. (Again, I'll show you how to control that with the sc sidtype command a bit later.)

Network restrictions A developer can design a service to tell Windows Firewall, "only let me communicate on port X."

We'll consider each in turn.




Administering Windows Vista Security. The Big Surprises
Administering Windows Vista Security: The Big Surprises
ISBN: 0470108320
EAN: 2147483647
Year: 2004
Pages: 101

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net