If my cmd.exe Window says "Administrator" in the title bar, indicating it was started with elevated privileges, does this mean anything I execute from this command window is also run with elevated privileges?

Specifically, if I run something like:

msiexec SomeProgram.msi

is my installer being run with elevated privileges because it was executed from a cmd.exe that was running with elevated privileges?

More specifically: I'm wondering if applications that present a UI and return the prompt in the cmd.exe window right away, like the msiexec call up above, are executing with elevated privileges.

Yes, it does execute with elevated privileges.

Simple test:

You can test this quite easily by opening one elevated and one non-elevated command prompt. Run the command notepad.exe in both, and try saving a blank text file to C:\Windows. One will save, one will throw a permissions error.

Thorough test:

If that's not enough to confirm it for you (it didn't really satisfy me) you can use AccessChk from SysInternals. You'll need to run this from an elevated command prompt.

Lets start by checking out the two Notepad processes that are running:

Notepad: (accesschk.exe -v -p notepad)

[11140] notepad.exe
  Medium Mandatory Level [No-Write-Up, No-Read-Up]
  RW EAGLEGROUP\Tannerf
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[11004] notepad.exe
  High Mandatory Level [No-Write-Up, No-Read-Up]
  RW BUILTIN\Administrators
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS

One is running under my domain username, the other is running under the Administrators built-in group. It also has a high mandatory level. You can also run with the -f flag for a breakdown of the privileges and tokens.

MSIExec and MSI files

I thought things might get a little more complicated when running msiexec. I have a Google Chrome standalone installer that was handy to test.

msiexec.exe launching Chrome installer from elevated prompt:

D:\Users\tannerf>accesschk.exe -p msiexec.exe

[10540] msiexec.exe
  RW BUILTIN\Administrators
  RW NT AUTHORITY\SYSTEM

chrome_installer.exe spawned by MSI:

D:\Users\tannerf>accesschk.exe -p chrome_installer.exe

[5552] chrome_installer.exe
     NT AUTHORITY\SYSTEM
     OWNER RIGHTS
  RW NT SERVICE\msiserver

Not so cut and dry anymore! Looks like a chrome_installer.exe processes was run through the MSIServer service.

This makes me wonder what behavior other installers might have, so I ran an Evernote.msi I had handy:

Elevated msiexec.exe launching an Evernote installer:

[6916] msiexec.exe
  High Mandatory Level [No-Write-Up, No-Read-Up]
  RW BUILTIN\Administrators
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[4652] msiexec.exe
  System Mandatory Level [No-Write-Up, No-Read-Up]
  R  BUILTIN\Administrators
        PROCESS_QUERY_INFORMATION
        PROCESS_QUERY_LIMITED_INFORMATION

Interesting; there's an msiexec.exe that's run under system level this time. I used Process Monitor to find that the actual install window that pops up comes from the system level msiexec process. Killing the high mandatory level also killed the system level process.

Non-elevated msiexec.exe launching an Evernote installer:

[7472] msiexec.exe
  Medium Mandatory Level [No-Write-Up, No-Read-Up]
  RW EAGLEGROUP\Tannerf
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[4404] msiexec.exe
  System Mandatory Level [No-Write-Up, No-Read-Up]
  R  BUILTIN\Administrators
        PROCESS_QUERY_INFORMATION
        PROCESS_QUERY_LIMITED_INFORMATION

Looks like Evernote will get system level access either way. Double-clicking the installer has the same result.

Conclusion:

I think it's pretty well demonstrated that a processes will inherit permissions unless otherwise specified. That doesn't guarantee msiexec SomeProgram.msi will run with a high mandatory level across all processes processes; it could run under system level or under MSIServer. Your mileage may vary, and I wouldn't be surprised to see many instances where these rules seem to be "broken".

By default, Windows processes will inherit their security context from the parent:

The ACLs in the default security descriptor for a process come from the primary or impersonation token of the creator.

^{MSDN on process security and access rights}

It is, however, possible to spawn processes with less privileges:

While processes inherit the integrity level of the process that spawned it, the integrity level can be customized at the time of process creation. As well as for defining the boundary for window messages in the User Interface Privilege Isolation technology, Mandatory Integrity Control is used by applications like Windows Explorer, Internet Explorer, Google Chrome and Adobe Reader to isolate documents from vulnerable objects in the system.

^{Wikipedia on Mandatory Integrity Control relating to this other MSDN page, also mentioned here. Another presentation also mentions process inheritance.}

However, I believe cmd.exe will launch child processes with the greatest level of privilege inheritance possible, as @Tanner's testing and answer shows.

There may be two ways to un-elevate the priviledges of the executed command:

• runas /trustlevel:0x20000 "msiexec SomeProgram.msi" (run runas /showtrustlevels to learn that 0x20000 is the default user trustlevel - this even works for installing/running programs that "require" elevated privileges - without actually granting them when run as admin. This passes Tanner's notepad test) as per this SU answer
• psexec -l -d msiexec SomeProgram.msi per this SU answer (maybe some "" are required as well, I didn't test this since runas works fine enough for me)