Impersonation vs. Job API

[Marco Mechelli]

Hello,

i'm facing with the following problem while using the Job API during an
impersonation.

I have a main process that needs to do the following:

1. Creates a new Job Object that will be used to handle its children.
2. Create a new process (either by CreateProcessW() or by
CreateProcessWithLogonW() for user impersonation).
3. Assign the newly created process to the previously created Job Object.

Now, if the main process uses the CreateProcessW() (i.e.: no impersonation)
everything works ok. The child process's parent is actually the main process
and the child is successfully assigned to the Job Object.

However, if the main process uses CreateProcessWithLogonW(), the child process
has 2 strange characteristics:

a. The parent is svchost.exe, not my main process
b. It is already part of a Job Object

In particular, because of b., since a process can belong to only one Job
Object, step 3 of the main process fails.

Now, the question is: how can I accomplish my need to have the process part of
my job object? Otherwise: is it safe to use the existing Job Object (made by
svchost) to manage the job (e.g. kill all the processes, get statistics, etc.)?
How can i obtain an handle to that job object?

This problem happens on all recent Windows versions (2k, XP, 2003).

Thanks,

marco

[Eric Hill]

I have a main process that needs to do the following:

>
1. Creates a new Job Object that will be used to handle its children.
2. Create a new process (either by CreateProcessW() or by
CreateProcessWithLogonW() for user impersonation).
3. Assign the newly created process to the previously created Job Object.

Ok.

However, if the main process uses CreateProcessWithLogonW(), the child
process
has 2 strange characteristics:

a. The parent is svchost.exe, not my main process
b. It is already part of a Job Object

In particular, because of b., since a process can belong to only one Job
Object, step 3 of the main process fails.

I don't see anything in the documentation specific to what
CreateProcessWithLogonW does, but this sounds like a reasonable problem to
have with that API call... :)

Now, the question is: how can I accomplish my need to have the process
part of
my job object? Otherwise: is it safe to use the existing Job Object
(made by
svchost) to manage the job (e.g. kill all the processes, get statistics,
etc.)?
How can i obtain an handle to that job object?

Instead of spawning a new process as a user, is it possible to use
LogonUser and ImpersonateLoggedOnUser to perform the tasks you need to
accomplish inside of a thread? The thread is bound by the rules of the
process, meaning you don't have to deal with svchost.exe trying to manage
your process...

Eric

[Eric Hill]

Instead of spawning a new process as a user, is it possible to use

LogonUser and ImpersonateLoggedOnUser to perform the tasks you need to
accomplish inside of a thread? The thread is bound by the rules of the
process, meaning you don't have to deal with svchost.exe trying to
manage your process...

On top of that, it looks like you can call CreateProcessAsUser with the
CREATE_BREAKAWAY_FROM_JOB bit set in the creation flags.

Found here:

http://groups.google.com/group/micro...2eef86a85e295e

Eric

[Marco Mechelli]

I tried it, but it doesn't work.
AFAIK, the problem is different: the CREATE_BREAKAWAY_FROM_JOB flag can be used
to allow a child process to be created out of the parent Job Object. In this
scenario, the parent is not within any job object!! Hence, the result is that
even if i use the flag, the child is still in svchost's job.

I'll give a try to the LogonUser+CreateProcess method ... and see

Thanks,

marco
Eric Hill wrote:

>Instead of spawning a new process as a user, is it possible to use
LogonUser and ImpersonateLoggedOnUser to perform the tasks you need to
accomplish inside of a thread? The thread is bound by the rules of
the process, meaning you don't have to deal with svchost.exe trying to
manage your process...

On top of that, it looks like you can call CreateProcessAsUser with the
CREATE_BREAKAWAY_FROM_JOB bit set in the creation flags.

Found here:

http://groups.google.com/group/micro...2eef86a85e295e
Eric

[Eric Hill]

I tried it, but it doesn't work.

AFAIK, the problem is different: the CREATE_BREAKAWAY_FROM_JOB flag can
be used
to allow a child process to be created out of the parent Job Object. In
this
scenario, the parent is not within any job object!! Hence, the result is
that
even if i use the flag, the child is still in svchost's job.

Isn't that the point? You don't want the newly created process to be
associated with a job, so that you can associate it with your own job.
Use the AssignProcessToJob API with the process id you get back from the
CreateProcessAsUser call to associate the process to your job and see what
happens.

I'll give a try to the LogonUser+CreateProcess method ... and see

Good luck!

Eric

[Marco Mechelli]

Eric,

thanks for the inputs, but i still have problems on both workarounds. See below
my comments ...

Eric Hill wrote:

>I tried it, but it doesn't work.
AFAIK, the problem is different: the CREATE_BREAKAWAY_FROM_JOB flag
can be used
to allow a child process to be created out of the parent Job Object.
In this
scenario, the parent is not within any job object!! Hence, the result
is that
even if i use the flag, the child is still in svchost's job.

Isn't that the point? You don't want the newly created process to be
associated with a job, so that you can associate it with your own job.
Use the AssignProcessToJob API with the process id you get back from the
CreateProcessAsUser call to associate the process to your job and see
what happens.

There's a subtle problem: as far as the CreateProcessWithTokenW returns to the
caller (the parent) the new child process is part of svchost's job. I guess it
is actually created by svchost and *then* added to the Job, hence the BREAKAWAY
parameter is useless in this context.

Anyway, i gave it a try and the result is AssignProcessToJob failing.

Using the same approach, i tried CreateProcessAsUserW, with an error 1307 being
returned, so ... no success!

>

>I'll give a try to the LogonUser+CreateProcess method ... and see

Good luck!

No way, as the documentation says, CreateProcess uses the original token of the
process, not the impersonation token, hence th child process does not
impersonate. One should use the CreateProcessAsUser but with the same problem
as CreateProcessWithLogonW ...

>
Eric

any ideas?

marco

[Eric Hill]

There's a subtle problem: as far as the CreateProcessWithTokenW returns

to the
caller (the parent) the new child process is part of svchost's job. I
guess it
is actually created by svchost and *then* added to the Job, hence the
BREAKAWAY
parameter is useless in this context.

Anyway, i gave it a try and the result is AssignProcessToJob failing.

Using the same approach, i tried CreateProcessAsUserW, with an error
1307 being
returned, so ... no success!

Drats. Another option under this scenario is to write a small "job
monitor process". Create your own executable that creates its' own job
object and launches whatever "other" processs you're trying to monitor,
and have it do nothing more than WaitForSingleObject on the job handle.
Then you can just WaitForSingleObject on your spawned executable from your
main process since you know it won't terminate until the job completes. I
KNOW this will work -- I've done it before. :)

>>I'll give a try to the LogonUser+CreateProcess method ... and see

Good luck!

No way, as the documentation says, CreateProcess uses the original token
of the
process, not the impersonation token, hence th child process does not
impersonate. One should use the CreateProcessAsUser but with the same
problem
as CreateProcessWithLogonW ...

Sorry, I misread your previous post. I was actually intending you to use
ImpersonateLoggedOnUser with the token from LogonUser, not CreateProcess.
Specifically, create a thread, impersonate the target user, then try
calling CreateProcess from within the thread. In theory the newly created
process would be running as the user from the impersonated thread, and
would assume the job context from the main process.

Eric

[Marco Mechelli]

Eric Hill wrote:

>There's a subtle problem: as far as the CreateProcessWithTokenW
returns to the
caller (the parent) the new child process is part of svchost's job. I
guess it
is actually created by svchost and *then* added to the Job, hence the
BREAKAWAY
parameter is useless in this context.

Anyway, i gave it a try and the result is AssignProcessToJob failing.

Using the same approach, i tried CreateProcessAsUserW, with an error
1307 being
returned, so ... no success!

Drats. Another option under this scenario is to write a small "job
monitor process". Create your own executable that creates its' own job
object and launches whatever "other" processs you're trying to monitor,
and have it do nothing more than WaitForSingleObject on the job handle.
Then you can just WaitForSingleObject on your spawned executable from
your main process since you know it won't terminate until the job
completes. I KNOW this will work -- I've done it before. :)

Yes right, same idea here, only problem is that i wanted to limit job creations
.... but i think that's the only "clean" way out of this maze. This really looks
like poor design in the intersection of these two sets of APIs
(impersonation+jobs).

I even tried putting myself in the job object before spawning, but nothing,
once CreateProcessWithToken returns, the child object belongs to another job
object (svchost's one). Needless to say ... CreateProcess with no impersonation
works ok in this case too ...

>

>>>I'll give a try to the LogonUser+CreateProcess method ... and see

Good luck!

No way, as the documentation says, CreateProcess uses the original
token of the
process, not the impersonation token, hence th child process does not
impersonate. One should use the CreateProcessAsUser but with the same
problem
as CreateProcessWithLogonW ...

Sorry, I misread your previous post. I was actually intending you to
use ImpersonateLoggedOnUser with the token from LogonUser, not
CreateProcess. Specifically, create a thread, impersonate the target
user, then try calling CreateProcess from within the thread. In theory
the newly created process would be running as the user from the
impersonated thread, and would assume the job context from the main
process.

I probably expressed it badly: that was actually what i did, but createprocess
ignores (i guess for security reasons) the thread's impersonation token and the
child process runs in the same security context as the main process before
impersonation. So the sequence
LogonUser->ImpersonateLoggedOnUser->CreateProcess actually produces a child
process running with same credential as the original main process' user.

>
Eric

[mailwrt]

"Marco Mechelli дµÀ£º
"

Eric Hill wrote:

There's a subtle problem: as far as the CreateProcessWithTokenW
returns to the
caller (the parent) the new child process is part of svchost's job. I
guess it
is actually created by svchost and *then* added to the Job, hence the
BREAKAWAY
parameter is useless in this context.

Anyway, i gave it a try and the result is AssignProcessToJob failing.

Using the same approach, i tried CreateProcessAsUserW, with an error
1307 being
returned, so ... no success!

Drats. Another option under this scenario is to write a small "job
monitor process". Create your own executable that creates its' own job
object and launches whatever "other" processs you're trying to monitor,
and have it do nothing more than WaitForSingleObject on the job handle.
Then you can just WaitForSingleObject on your spawned executable from
your main process since you know it won't terminate until the job
completes. I KNOW this will work -- I've done it before. :)

Yes right, same idea here, only problem is that i wanted to limit job creations
... but i think that's the only "clean" way out of this maze. This reallylooks
like poor design in the intersection of these two sets of APIs
(impersonation+jobs).

I even tried putting myself in the job object before spawning, but nothing,
once CreateProcessWithToken returns, the child object belongs to another job
object (svchost's one). Needless to say ... CreateProcess with no impersonation
works ok in this case too ...

>>I'll give a try to the LogonUser+CreateProcess method ... and see

Good luck!

No way, as the documentation says, CreateProcess uses the original
token of the
process, not the impersonation token, hence th child process does not
impersonate. One should use the CreateProcessAsUser but with the same
problem
as CreateProcessWithLogonW ...

Sorry, I misread your previous post. I was actually intending you to
use ImpersonateLoggedOnUser with the token from LogonUser, not
CreateProcess. Specifically, create a thread, impersonate the target
user, then try calling CreateProcess from within the thread. In theory
the newly created process would be running as the user from the
impersonated thread, and would assume the job context from the main
process.

I probably expressed it badly: that was actually what i did, but createprocess
ignores (i guess for security reasons) the thread's impersonation token and the
child process runs in the same security context as the main process before
impersonation. So the sequence
LogonUser->ImpersonateLoggedOnUser->CreateProcess actually produces a child
process running with same credential as the original main process' user.

Eric

I'm facing with the similar problem.

LogonUser->ImpersonateLoggedOnUser->CreateProcess doesn't create a
child process with another credential, otherwise, I think the calling
process need SE_ASSIGNPRIMARYTOKEN_NAME privilege.

The differences I'm facing with are that my code called
AssignProcessToJobObject function successfully when adding a process to
the job object. The process was created by CreateProcessAsUser with a
token of Guest's account created by LogonUser, but it seems that the
process exits immediately without any error returned when it resumes
executing. When I tried to add a process with a restricted token of the
calling process to the job object, everything went well.

Maybe only Microsoft knows whether a process with a different token can
be assigned to the job object created by the parent process :-(