@PID, v31 vs. v32

[vefatica]

The ISAPP conditional expression test does this also. Below both are unelevated. The error message does not appear when v32 is elevated.

 

[Alpengreis]

@vefatica

Here your examples working without problems unelevated with v32 ...

 

[vefatica]

It has something to do with START /UNELEVATED (my own RUNDOWN.EXE and SPOOFPPID.EXE, too). I was starting the unelevated v32 with one of those three. It's OK if I start the unelevated v32 in a more conventional way (Explorer, Start\Run, ...). I think it might have something to do with the started process having/getting the SE_DEBUG_NAME privilege (but I could be way off).

 

[rconn]

@PID hasn't changed in several years.

START has never set / unset the SE_DEBUG_NAME privilege.

 

[vefatica]

START has never set / unset the SE_DEBUG_NAME privilege.

I'm not sure SE_DEBUG_NAME is the culprit (the help mentions it in connection with ISAPP) but both ISAPP and @PID give the error message when TCC was started by an elevated instance with START /UNELEVATED. When that happens, the ISAPP test fails and @PID gives the right answer in spite of the error message. They work OK in unelevated instances not started with START /UNELEVATED.

 

[vefatica]

Just as a test, I uncommented (and added a Printf to) a line in InitializePlugin. I used to use it until I discovered it wasn't necessary (since I'm always an admin).

Printf(L"%d\r\n", EnableDebugPriv(TRUE));

Except for the case when TCC is started by START /UNELEVATED, it works ("1" is printed). When TCC is started by START /UNELEVATED, I see this.

TCC: (Sys) Access is denied.
 "OpenProcessToken"
0

The call that fails is this one.

if ( OpenProcessToken( GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken ) ) ...

 

[Alpengreis]

You meant probably it works with START /ELEVATED above ...

However: "interesting" case again.

Could this be relevated to the user environment somehow??

 

[vefatica]

You meant probably it works with START /ELEVATED above ...

I think I said it correctly.

 

[Alpengreis]

Except for the case when TCC is started by START /UNELEVATED, it works ("1" is printed). When TCC is started by START /UNELEVATED, I see this.

I read both time the same: START /UNELEVATED ...

 

[Charles Dye]

I have a plugin that does this — though I no longer remember why — and I can confirm that START /UNELEVATED causes OpenProcessToken(GetCurrentProcess(),...) to fail.

Does this constitute an actual problem? I really don't know.

 

[vefatica]

Does this constitute an actual problem? I really don't know.

It was a small problem for me at first. I was editing/debugging a STARTOUTLOOK.BTM which used IF ISAPP and I was getting the unexpected "Access is denied" messages. That BTM won't run elevated and since I'm usually in an elevated TCC, I needed to start an unelevated one for testing. I used START /UNELEVATED (though I have other ways of doing the same thing) and I noticed the anomaly. Now that I know what's going on, it's no longer a problem.

I'm still curious about whether the behavior can be changed ... whether you can spoof the parent PID (a la Raymond Chen) and not get a default/lame set of privileges.

 

[vefatica]

As I (not very accurately) said before, all of these work in a TCC started with START /UNELEVATED in spite of the error message. I wonder where the error comes from and if it could be expected and ignored, at least in some cases. IF ISAPP tcc.exe doesn't work but that's another story.

v:\> echo %@pid[outlook.exe]
TCC: (Sys) Access is denied.
7804

v:\> echo %@pid[utlook.exe]
TCC: (Sys) Access is denied.
0

v:\> if isapp tcc (echo yes) else (echo no)
TCC: (Sys) Access is denied.
yes

v:\> if not isapp tcc (echo no) else (echo yes)
TCC: (Sys) Access is denied.
yes