I was called to task because in Writing Secure Code for Windows Vista, I asserted that from the standpoint of a service, the impersonation privilege isn't dangerous. SeImpersonate is one of the newer privileges in Windows, and has only been put there since Windows 2003 (and is in XP SP2). Basically, the attack it is trying to prevent is one where you can get a higher-level process to connect to some resource you have, impersonate them, and escalate privilege. This can happen in a number of ways:
So it's starting to sound as if impersonation was enemy #2 (just behind buffer overruns) - why would I say it's benign? Here's the deal - by default, local system, local service, and network service are allowed to impersonate callers. To get to be running as any of these user accounts, you've got to have a service installed by an admin (or a hideously misconfigured service ACL), and if you're being attacked by the admin, just give up - it's game over. The second way you get to be one of these services, is by finding some sort of ghastly flaw in the service, taking it over, and causing it to do your bidding. Sounds like a plausible attack, so let's think about how that might work. If you've manged to own up a local system service, game over, and you win. Next, work on taking over the rest of the network (which you of course have permission from the owner to conduct pen testing on, or you risk serious consequences, like a new, unfriendly roommate in a very bad, long-stay facility). So let's say you've managed to take over a service running as the local service account - surely you can trick something running as local system to connect to you, and do rotten things. If you can, then there's a flaw in the local system service - the local system service should NEVER assume that any less privileged process is doing anything other than running malicious code. Whether the service running as local service has SeImpersonate or not, if the higher level process trusts them, they're making a mistake.
But what if an unwary admin connects to a service? Sorry - same rules apply. If you're running as admin, you're equivalent to local system (since you can install new drivers and services). If you put trust in anything running with less privileges that's on the system, it's your mistake - or the person writing the software has made a mistake.
The point here is that the service that has SeImpersonate isn't what is at risk here. The users connecting to the service are at risk, if they allow themselves to be fully impersonated.
Now let's look at the flip side - if a service ought to be impersonating, and is not, then we have an opportunity for what's called a luring attack. In a luring attack, one user tricks another into doing something on their behalf that ought not happen. Impersonation prevents luring attacks, because the action is being performed as the calling user. If you're doing something on behalf of another user, _not_ impersonating is very likely to be a problem. We can't say that impersonation is really just scary and ought not be used - then we'd have luring attacks all over the place.
Impersonation is a complex issue, and using it really correctly is something that ought to be covered much more thoroughly than what we did in either WSC2 or WSCV. Here's the bottom line:
The whole topic is fairly complicated, so I might spend some time on it in the future. Another wrinkle worth a future post is how you manage when you can't impersonate, but you can identify the caller. There's a bunch of relatively new functionality that makes this problem a lot easier.