WindowsIntegrityLevel Type
The Windows *mandatory integrity level* a child's token is lowered to — see `Command.WindowsIntegrityLevel`. Windows labels every token (and every securable object) with an integrity level and enforces a no-write-up policy: a process may not modify an object labelled above its own level, whatever the DACL says. Lowering the level a child runs at therefore takes away write access to the user's own files, registry, and windows *without* changing who the child runs as — the closest Windows analogue to the Unix `Uid`/`Gid` drop, and the mechanism behind browser renderer sandboxes. Only levels at or below an ordinary process's own are offered: a token's integrity can be lowered but never raised (`SetTokenInformation` refuses), so an "elevate me" variant could only ever fail the spawn. Pair with `Command.WindowsRestrictedToken` for the full drop — the two are independent (integrity governs what may be *written to*, privileges govern what may be *done*).
Union cases
| Union case |
Description
|
Full Usage:
Low
|
`S-1-16-4096` — the sandbox level: no write access to the user's profile, `HKCU`, or the desktop's medium-integrity windows. A child at this level can still read most of the file system and open network connections; it writes only where a low-integrity label allows (its own `%TEMP%\Low`, for instance). The usual choice for untrusted work that must still produce output through the pipes ProcessKit already opened for it (inherited handles are unaffected — the access check happened when the parent opened them). |
Full Usage:
Medium
|
`S-1-16-8192` — the level an ordinary, non-elevated user process already runs at. Meaningful mainly from an **elevated** parent, where it drops the child back to the level the logged-on user's own programs run at instead of inheriting the parent's High integrity. |
Full Usage:
Untrusted
|
`S-1-16-0` — the most restrictive label Windows has: below even anonymous access, with no write access anywhere by default. Many programs cannot start at all here (a runtime that must write a temp file, load a user-profile DLL, or open a named object will fail), so treat it as a deliberate, tested choice for a self-contained binary rather than a stricter default. It is never a silent downgrade: whatever the child can no longer do surfaces as that child's own failure, not as a ProcessKit error. |
Instance members
| Instance member |
Description
|
Full Usage:
this.IsLow
Returns: bool
|
|
Full Usage:
this.IsMedium
Returns: bool
|
|
Full Usage:
this.IsUntrusted
Returns: bool
|
|
ProcessKit API Reference