mailing list archives
Re: Question for the Windows pros
From: Paul Schmehl <pauls () utdallas edu>
Date: Wed, 18 Jan 2006 12:07:14 -0600
--On Wednesday, January 18, 2006 11:40:00 -0600 Frank Knobbe
<frank () knobbe us> wrote:
I understand *that*. My question is, what are you granting them "su"
*for*? The entire kettle of fish? Or specific tasks. The privilege only
allows you to impersonate a *client* (as in server-client), so (I would
think) you can't do file browsing or http parsing (or can you?)
On Wed, 2006-01-18 at 11:30 -0600, Paul Schmehl wrote:
I can read. I need to know, from a practical application standpoint,
what does this mean. What are the exposures?
Sounds to me like that right allows a user to assume the security
context of another user. Think of "RunAs" where a user runs a procedure
as a different user.
*That* ability should tell you a lot of what the exposures are. It's
seems similar to allowing your *nix users to use su (without password
check) to assume another user. (As root you can "su username" and you
are that user. Imagine of your normal users could do that).
IOW, what are the *servers* that you can impersonate the client for? Is
Windows Explorer a server, for example? Does it allow clients to access
it? Is IE a server? Obviously, all the *services* (or at least the
majority of them) would be servers - such as the Computer Browsing service
- but does that service allow clients to access it? Or the Alerter
service. Does it allow clients?
The explanations on MS's site are vague enough that they're meaningless.
What services running on Windows allow clients to access them? And if they
do, do they restrict access to the Local Machine? Or do they allow Remote
Access? (For example, RPC is clearly remote. Is the Windows Time service?)
Knowing the answers to those would go a long way toward answering the
question - what exactly are the capabilities that this privilege grants you?
Unfortunately, in the context of my problem, the users must have this
right. Before I grant it, I want to understand exactly what the
ramifications of that are. If it's too severe a risk, then I'll have to
find some other way to solve this problem.
I don't see why you would ever need to grant a normal user such a right.
It may be of interest for service accounts, though.
Paul Schmehl (pauls () utdallas edu)
Adjunct Information Security Officer
University of Texas at Dallas
AVIEN Founding Member
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/