RE: using CreateProcessAsUser API
- From: Eric Perlin [MSFT] <EricPerlinMSFT@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 13 Dec 2006 16:36:00 -0800
Standard users can create directories at the root of the system drive, and
files and more sub-directories in them.
Just create a standard user, logon as that user, and create a directory at
the root of the system drive.
Here's why:
The SDDL of %systemdrive%\ is
"D:(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICIIO;GA;;;CO)(A;OICI;0x1200a9;;;BU)(A;CI;LC;;;BU)(A;CIIO;DC;;;BU)(A;;0x1200a9;;;WD)"
The ACEs of interest are (A;CI;LC;;;BU)(A;CIIO;DC;;;BU)
LC corresponds to FILE_ADD_SUBDIRECTORY, so the first ACE allows members of
the builtin users group (BU) to create directories, and it's inheritable so
they can also create directories further down.
DC corresponds to FILE_ADD_FILE, allowing creation of files the same way,
but with a twist (since it's a inherit only ACE, it doesn't apply on the root
itself, so standard users can't create files at the root).
Of course, this doesn't apply to the other builtin top level directorirs,
which have their own protected DACL...
If you were to disable the BU when creating your process, it may not even
get to start (won't be able to read its own executable), so that's a non
starter.
ReACL the root of the system drive (and files and directories inheriting
their DACL from there) would be another solution but it's unlikely to be
popular, especially if you removed rights...
So you may be left with one last option, which is a yet undocumented flag of
CreateRestrictedToken called WRITE_RESTRICTED. With that additional flag,
instead of doing the double accesscheck with the restricted sids list all the
time, that second list of sids is only used for write attempts.
It makes it possible to build a token that can't write anywhere (when all
the user's sids are on the restricted list of a write restricted token).
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Eric Perlin [MSFT]
"kunal s patel" wrote:
Hi,.
Thanx for the help...i cud solve the problem(and yes it was my typo
service runs under local system account) but now i m facing some other
problem.....
Now my process starts properly under the account i want it to(xyz).....but i
cannot
understand one thing now....i created the account xyz but didnt add ny
privileges to it
(i double checked it by enumerating privileges)......now when my exe
file(fired from
service under xyz account security context) tries to create a directory, it
is able to do so...i dont understand
how is it possible?? Also wat the way of disabling it....exe shud not be
able create ny file or directory
in the system...n if it tries to do it...it shud fail
kunal
"kunal s patel" wrote:
y Hi
I am creating a dummy account in a service and then run the process under
that account using the above api. Now something very wierd
happens......process is created properly...i get proper process id but it
doesnt run the executable.....here r the privileges i included into account
SE_ASSIGNPRIMARYTOKEN_NAME,SE_INCREASE_QUOTA,SE_CREATE_PERMANENT_NAME,SE_CREATE_TOKEN_NAME
and i m using API as
if(!CreateProcessAsUser(newtoken,NULL,"C:\\sim0.exe",0,0,FALSE,CREATE_NEW_CONSOLE
,NULL,NULL,&startupinfo,&procinfo))
kunal
- Follow-Ups:
- RE: using CreateProcessAsUser API
- From: kunal s patel
- RE: using CreateProcessAsUser API
- Prev by Date: How can a program talk to Windows Security Center?
- Next by Date: Re: Repost: Using SetTokenInformation to control file system virtualization on Vista?
- Previous by thread: RE: using CreateProcessAsUser API
- Next by thread: RE: using CreateProcessAsUser API
- Index(es):
Relevant Pages
|
