Re: Win32 security limitations: why?
From: Roger Abell (mvpNOSpam_at_asu.edu)
Date: 06/17/05
- Next message: IT Boy: "Re: Automatically updated?"
- Previous message: Roger Abell: "Re: Win32 security limitations: why?"
- In reply to: Peter: "Win32 security limitations: why?"
- Next in thread: Peter: "Re: Win32 security limitations: why?"
- Reply: Peter: "Re: Win32 security limitations: why?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 16 Jun 2005 17:48:15 -0700
Can you supply sample asp code for this?
In the early morn blur I mixed up spawn on-box and off-box,
and your later post make clear you are speaking of on box.
As that does not involve new authentication, the impersonating
process should just pass copy of its own token to the child
process, unless a RevertToSelf call is involved.
-- Roger Abell Microsoft MVP (Windows Security) "Peter" <nobody@nospam.nl> wrote in message news:uO9snqmcFHA.1040@TK2MSFTNGP10.phx.gbl... > Hi, > > Trying to spawn a process from an impersonated client from within IIS-ASP I > came across some (in my opinion) weird behaviour. > > 1) CreateProcess and ShellExecute both create the new process using the > current process-token, yielding in a process running under the IWAM_xxx > account. This happens even if the client was an anonymous user! > I just don't understand this behaviour. Other operating systems I know will > spawn the process from the *current* security context, so under the > imporsonated client. > Doing it on the MS-way enables anonymous users to create process with a > higher security level. Thats a major security risk! Or not? Can someone put > some light on it, or point me to more detailed information about why MS > implemented security the way thay did? > > 2) Its even impossible with CreateProcessAsUser() to create the process > under the imporsonated account because the SeAssignPrimaryTokenPrivilege > must be held (and by default nobody does...) > > 3) I also needed to load the user hive, so I tried LoadUserProfile(). > Also this API needed a privilege: the SeRestorePrivilege. Since the > imporsonated user is a "normal" user, it didn't held this privilege, so the > account couldn't load its own profile! Why is that? I understand that > loading another user's profile is a security risk, but loading your own > profile is definitly not. > > I would like to understand more about the why's. Please help. > Thanks a lot. > > Peter > > >
- Next message: IT Boy: "Re: Automatically updated?"
- Previous message: Roger Abell: "Re: Win32 security limitations: why?"
- In reply to: Peter: "Win32 security limitations: why?"
- Next in thread: Peter: "Re: Win32 security limitations: why?"
- Reply: Peter: "Re: Win32 security limitations: why?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|