Programming Microsoft Windows Ce Net 3Rd [Electronic resources] نسخه متنی

Windows CE Security

While Windows CE doesn't implement the thread- and process-level security of the Windows NT/2000/XP line, it does have an optional level of module-based security. This security scheme is based on the concept of trusted and untrusted modules. The modules are the executables (.EXEs) and dynamic-link libraries (DLLs). Trusted modules can access anything in the system, while untrusted modules are refused access to a handful of protected functions and registry keys.

The Windows CE security scheme must be implemented by the OEM when it ports Windows CE to its hardware. When an executable or DLL is loaded, the operating system notifies the OAL, the OEM abstraction layer, underneath the operating system. The OAL then decides, by whatever means it chooses, to mark the executable or DLL as being trusted or untrusted. This check happens only for modules loaded from the object store or external media. In most cases, modules loaded directly from ROM are assumed to be trusted because the OEM made the decision about what modules were present in the ROM. However, this ROM module trust assumption can be disabled by the OEM. For systems that don't implement this security scheme, all modules are considered trusted.

Because trusted modules have free reign, the only interesting case is what happens if a module is untrusted. When an untrusted module calls a protected function, such as the function VirtualCopy, the call fails. Calling GetLastError then returns ERROR_ACCESS_DENIED. A handful of registry keys and their descendants are also protected. Untrusted modules can read a protected registry key, but any attempt to modify a protected key or create values or keys underneath a protected key results in an ERROR_ACCESS_DENIED failure. A list of the protected functions^[3] and registry keys is shown in Listing 10-1. In addition to the list, files marked with the FILE_ATTRIBUTE SYSTEM attribute can't be moved, changed, or deleted by untrusted applications. Databases with the SYSTEM flag can't be modified by untrusted applications.

Listing 10-1: The list of protected functions and registry keys

Functions
AllocPhysMem                RegCopyFile     
CeSetThreadPriority         RegReplaceKey 
CeSetThreadQuantum          RegRestoreFile 
CheckPassword               RegSaveKey 
CryptUnprotectData          SetCleanRebootFlag
DebugActiveProcess          SetCurrentUser 
ForcePageout                SetInterruptEvent   
FreeIntChainHandler         SetKMode
FreePhysMem                 SetPassword 
InterruptDisable            SetPasswordStatus 
InterruptDone               SetProcPermissions
InterruptInitialize         SetSystemMemoryDivision
KernelLibIoControl          SetUserData 
LoadDriver                  SystemStarted          
LoadIntChainHandler         UnlockPages
LoadKernelLibrary           VirtualCopy            
LockPages                   VirtualSetPageFlags 
PowerOffSystem              WaitForDebugEvent 
ReadProcessMemory           WriteProcessMemory
ReadRegistryFromOEM         WriteRegistryToOEM      

Registry Keys
HKEY_LOCAL_MACHINE\Comm 
HKEY_LOCAL_MACHINE\Drivers 
HKEY_LOCAL_MACHINE\Services 
HKEY_LOCAL_MACHINE\HARDWARE 
HKEY_LOCAL_MACHINE\SYSTEM 
HKEY_LOCAL_MACHINE\init 
HKEY_LOCAL_MACHINE\WDMDrivers

There are a few interesting derivations of this security scheme. What happens when a trusted executable unknowingly loads an untrusted DLL? What if an untrusted executable loads a trusted DLL? Finally, how is a device driver supposed to react to a call from an untrusted module? Actually, the rules are fairly simple.

If a trusted module attempts to load an untrusted DLL, the load fails. If an untrusted module loads a trusted DLL, the trust level of the DLL is reduced to untrusted. A module can determine its trust state by calling the function

DWORD CeGetCurrentTrust (void);

The return value for this function is either OEM_CERTIFY_TRUST, which signifies that the module is running in a trusted state, or OEM_CERTIFY_RUN, which indicates that the module is currently untrusted. If a module requires access to trusted functions, it can call CeGetCurrentTrust at its initialization, and if it discovers that it's running in an untrusted state, it can fail its initialization.

Device drivers operate in a different process space from standard applications, but sometimes a device driver might need to check the trust state of a calling application. Here's the function that accomplishes this task:

DWORD CeGetCallerTrust (void);

The return values are the same as for CeGetCurrentTrust, OEM_CERTIFY_TRUST, and OEM_CERTIFY_RUN.

^[3] A number of undocumented functions are also protected but are not included in this list.