Application Execution Security 101

This post will be a quick reference to the application security model
in WM 2005. I'll gloss over some fine details in order to cover the
broad points.

For CreateProcess() or running any executable
  First, examine the signature
on the binary. The three possibilities are that it is signed
privileged, signed unprivileged, or unsigned. (determined by checking
the Authenticode signature)

If signed by cert that chains to Privileged Execution Authorities store:

App runs privileged(CeGetCurrentTrust() == 2)

Else if signed by cert that chains to Unprivileged Execution Authorities store:

If device is one-tier (policy 4123 == 1)

App runs privileged.

else (two-tier)

App runs unprivileged. (CeGetCurrentTrust() == 1)

Else if app is unsigned

If unsigned apps are blocked (policy 4102 == 0)

App fails to load. (returns NTE_BAD_SIGNATURE).

Else if the device prompts, and the prompt times out or the user presses No

App fails to load.

Else if we are configured not to prompt (policy 4122 == 1) or the user accepts the prompt

If device is one-tier

App runs trusted.

else (two-tier)

App runs untrusted.

LoadLibrary

The rules for DLLs are very similar, with the following differences.

• A process cannot load a DLL of lower trust. A process with trust level 2 will fail to load a DLL with trust level 1.
• A DLL can be loaded into a process
  of lower trust, it just runs at the process trust level. A DLL signed
  with a privileged certificate can be loaded into an unprivileged
  application, but it will run unprivileged.

Comments

• Anonymous
  April 07, 2006
  The comment has been removed
• Anonymous
  April 08, 2006
  Yes - trust is a property of a process, and the DLL is loaded into an unprivileged process. So it still behaves as if it were unprivileged.