Advanced Token Settings
The settings on this page alter how Sandboxie filters or reconstructs Windows access tokens. Most are advanced compatibility or debugging options that preserve properties Sandboxie would normally remove or restrict. They should generally be used only when required for compatibility or specialized testing.
These settings affect token-based isolation only. File-system and registry virtualization, IPC controls, network restrictions, GUI isolation, and other independent Sandboxie mechanisms remain separate.
Token processing stages
The relevant part of token processing can be simplified as follows:
original primary token
|
v
preliminary filtering
|
|-- UnfilteredToken can skip this stage
|
v
restriction / reconstruction
|
|-- UnrestrictedToken can skip this stage
|
|-- the normal modern path reconstructs the token
|
v
sandbox primary token
The preliminary filter and the later restriction or reconstruction stage are separate. Consequently, UnfilteredToken does not mean that the token is unrestricted, and UnrestrictedToken does not restore properties removed by preliminary filtering. Enabling both preserves substantially more characteristics of the source token than enabling either one alone.
Sandboxie has a modern token-construction path and a legacy filtering path. Current normal configurations commonly use the modern Token_CreateToken path because SandboxieAllGroup has a runtime default of enabled; UseCreateToken can also select that path. This distinction is particularly important for UnstrippedToken, whose behavior differs between the two paths.
This is a conceptual outline of token processing, not the complete Sandboxie isolation model.
Common syntax and scope
All settings on this page are box-wide Boolean settings:
Current runtime lookups are not executable-qualified, so syntax such as SettingName=program.exe,y is not supported for these settings. Normal Sandboxie configuration and template inheritance can still affect the effective configuration of a box.
NoUntrustedToken
NoUntrustedToken defaults to n in both the setting metadata and the current runtime. The normal restricted sandbox token uses the Windows Untrusted integrity level. When NoUntrustedToken is enabled, Sandboxie uses Low integrity instead.
This setting does not disable token replacement or restriction, preserve the source integrity level, or disable security isolation. It changes the sandbox token's lowered integrity level from Untrusted to Low while leaving the remaining token-isolation steps active.
If KeepTokenIntegrity is enabled, the normal integrity reduction is skipped, making the Untrusted-versus-Low choice irrelevant. The setting is also redundant when NoSecurityIsolation=y bypasses normal primary-token replacement.
SandMan exposes this setting at:
Sandbox Options > Security Options > Advanced Security
The checkbox is labeled Use LOW integrity token instead of UNTRUSTED (reduces isolation).
UnfilteredToken
UnfilteredToken defaults to n. It skips Sandboxie's preliminary token-filtering stage. That stage normally removes a fixed set of sensitive privileges and also applies DropAdminRights filtering when configured.
Later restriction or reconstruction still occurs. The resulting token can therefore still receive a substituted token user or lower integrity level, have groups converted to deny-only, lose privileges during reconstruction, and receive Sandboxie-specific token groups.
In short, UnfilteredToken skips the preliminary filtering stage; later token-restriction or reconstruction steps may still modify the token. Current code also consults this behavior during relevant impersonation-token validation and WTS token handling.
Because DropAdminRights participates in the preliminary filter, UnfilteredToken can bypass that preliminary removal of administrator-related groups and selected privileges. It does not remove the later Sandboxie restrictions.
UnrestrictedToken
UnrestrictedToken defaults to n. It skips the heavy token-restriction or reconstruction stage, causing Sandboxie to duplicate the token received from the earlier stage.
That token may already have been modified by preliminary filtering. Enabling UnrestrictedToken alone does not restore groups, privileges, or other properties removed earlier.
UnrestrictedToken skips the normal heavy token-restriction stage, but other Sandboxie isolation mechanisms remain active and earlier token filtering may already have modified the token. It does not disable file-system or registry virtualization and isolation, IPC controls, network restrictions, or other independent sandbox mechanisms.
UnfilteredToken versus UnrestrictedToken
| Configuration | Preliminary filter | Restriction/reconstruction |
|---|---|---|
| Normal | Applied | Applied |
UnfilteredToken=y |
Skipped | Still applied |
UnrestrictedToken=y |
Still applied | Skipped |
| Both enabled | Skipped | Skipped |
Using both options preserves substantially more characteristics of the source token than either option alone. It does not completely disable Sandboxie because the other isolation layers remain independent.
ReplicateToken
ReplicateToken defaults to n and applies specifically to the modern Token_CreateToken reconstruction path. It creates a new token while preserving substantially more properties from the source token; it does not simply duplicate the original token object.
The reconstructed token preserves or reuses the source token user, groups, privileges, token type, impersonation level, authentication ID, expiration, owner, primary group, default DACL, and token source. It also avoids several normal transformations, including Sandboxie or Anonymous token-user substitution, conversion of groups to deny-only, normal privilege reduction, and normal addition of the SandboxieAll group.
ReplicateToken additionally enables optional device-group retrieval and token security-attribute copying, regardless of explicit CopyDeviceGroups=n or CopyTokenAttributes=n values. Neither optional operation guarantees successful preservation; see the following sections for their separate behavior and limitations.
The source token passed to this stage may already have undergone preliminary filtering unless UnfilteredToken is also enabled. ReplicateToken therefore does not necessarily restore groups or privileges removed earlier.
The implementation does not explicitly copy every token information class. Research did not establish explicit copying of TokenRestrictedSids, TokenOrigin, TokenSessionId, or AppContainer capabilities. ReplicateToken reconstructs the sandbox token while preserving substantially more properties of its source token; it should not be treated as an exact clone of every token field.
CopyDeviceGroups
CopyDeviceGroups requests preservation of the source token's TokenDeviceGroups during modern token reconstruction. Its consumer fallback is n when no effective value is configured. It is a box-wide Boolean setting: applicable enabled templates and GlobalSettings fallback can contribute to the effective configuration, but executable-specific selectors are not supported.
It applies to the modern reconstruction described under Token processing stages, not legacy filtering or the duplication selected by UnrestrictedToken. An explicit UseCreateToken=y is not required: the modern path can also be selected by SandboxieAllGroup or when the legacy filter is unavailable. Enabling CopyDeviceGroups does not itself select that path.
ReplicateToken enables the device-group copy decision even when CopyDeviceGroups=n is explicitly configured. These settings are not aliases: CopyDeviceGroups requests only this optional field, not the broader preservation performed by ReplicateToken.
Retrieval is best effort. Sandboxie needs a usable source-token handle and must successfully query and allocate space for the device-group information. If the handle is unavailable, allocation fails, or the queries cannot retrieve the information, construction can continue without it.
Transfer also depends on the available token constructor. The extended ZwCreateTokenEx path accepts device groups; the older ZwCreateToken fallback does not. A failure of the extended constructor does not automatically trigger a retry without device groups. Enabling the setting therefore does not guarantee preservation on every supported system.
Device groups are distinct from ordinary token groups (TokenGroups), token security attributes (TokenSecurityAttributes), and AppContainer capabilities. They are not a list of hardware devices. This setting does not control ordinary group membership or deny-only conversion, SandboxieAll group insertion, user SID substitution, integrity reduction, privilege reduction, or the separate CopyTokenAttributes operation.
Preserving device-group information does not itself restore administrator privileges, change device ACLs, disable Sandboxie device restrictions or file and Registry virtualization, bypass other security controls, or grant unrestricted host-device access. It does not guarantee application compatibility.
CopyTokenAttributes
CopyTokenAttributes applies to the modern Token_CreateToken path and refers specifically to TokenSecurityAttributes. Sandboxie reads these security attributes from the source token and adds them to the newly created token. The setting does not copy every token information class and does not mean that AppContainer capabilities are copied.
There is an important difference between the metadata and current runtime defaults:
- the setting metadata lists a default of
n; - the current
Token_CreateTokenimplementation usestrueas the runtime default when the setting is absent.
As a result, token security attributes are copied by default on that path in the current implementation. Setting CopyTokenAttributes=n explicitly disables this optional copy. Enabling ReplicateToken forces the copy behavior regardless of the explicit CopyTokenAttributes value.
Attribute copying occurs after the new token is created and is best effort. Failure while querying, allocating, or applying TokenSecurityAttributes does not invalidate an otherwise successfully created token.
KeepTokenIntegrity
KeepTokenIntegrity defaults to n. Sandboxie normally replaces the source integrity SID with a lowered sandbox integrity level. Enabling this setting preserves the source token's integrity level instead, so a token that begins at High integrity can remain at High integrity.
Integrity level, group membership, and privileges are separate token properties. KeepTokenIntegrity preserves the source integrity level; token groups and privileges are filtered independently. It does not undo DropAdminRights and does not change the compatibility behavior of FakeAdminRights.
Enabling this setting makes NoUntrustedToken irrelevant. It is also redundant when normal primary-token replacement is bypassed by NoSecurityIsolation.
KeepUserGroup
KeepUserGroup defaults to n. Here, "user group" means the token group entry whose SID matches the token's TokenUser. It does not specifically mean BUILTIN\Users, the SandboxieAll group, or the logon SID.
During normal group restriction, Sandboxie can disable groups or convert them to deny-only. With KeepUserGroup enabled, the group matching the token user SID is preserved instead of receiving that normal treatment. The TokenUser identity itself can still be substituted later by the normal Anonymous Logon or Sandboxie SID path.
UnstrippedToken
UnstrippedToken defaults to n. It skips selected stripping operations, but the exact preserved properties depend on the token-construction path.
Modern token-construction path
On the modern Token_CreateToken path, enabling UnstrippedToken skips the normal group-restriction transformations and integrity-level replacement. Normal token-user substitution still occurs, and privileges are still reduced to the modern path's restricted privilege set, which normally retains SeChangeNotifyPrivilege.
It therefore does not preserve every token component.
Legacy filtering path
On the legacy path, integrity handling occurs before the UnstrippedToken early return. Later group stripping and restriction steps are skipped. Consequently, the setting does not imply KeepTokenIntegrity uniformly across both implementations.
UnstrippedToken acts later and more narrowly than UnfilteredToken, is less comprehensive than UnrestrictedToken, and is not an alias for either one. The modern behavior is the most relevant to current normal configurations, but the legacy distinction still exists under other configurations or platform conditions.
Interaction with NoSecurityIsolation
When NoSecurityIsolation=y, Sandboxie normally bypasses primary-token replacement. The settings described on this page are therefore generally redundant or not reached for the normal primary token:
- NoUntrustedToken
- ReplicateToken
- CopyDeviceGroups
- CopyTokenAttributes
- UnfilteredToken
- UnrestrictedToken
- KeepTokenIntegrity
- KeepUserGroup
- UnstrippedToken
See No Security Isolation for the wider effects of that mode.
Interaction with administrative-rights settings
DropAdminRights performs real token filtering, including disabling administrator-related groups and removing selected privileges. UnfilteredToken can bypass its preliminary filtering stage, while UnrestrictedToken alone does not restore properties already removed there. KeepTokenIntegrity can preserve a High integrity level without restoring administrative groups or privileges.
FakeAdminRights is different: its current implementation primarily uses compatibility hooks to make selected administrator checks appear successful. It does not restore real administrator groups or privileges removed by token filtering.
SandMan configuration
Among the settings on this page, only NoUntrustedToken has a dedicated current SandMan control:
Sandbox Options > Security Options > Advanced Security > Use LOW integrity token instead of UNTRUSTED (reduces isolation)
The remaining settings are advanced manual Sandboxie.ini options. For CopyDeviceGroups, use Sandbox Options > Edit ini Section > Edit ini; there is no dedicated checkbox.
Sandboxie Plus and Classic
Token processing is implemented in shared Sandboxie components. SandMan exposes the NoUntrustedToken control, while the other settings on this page use manual configuration. Current source does not contain equivalent dedicated Sandboxie Control Classic controls, but compatible manual INI settings can be consumed by the shared runtime where applicable. Classic provides manual editing through Configure > Edit Configuration.
Applying configuration changes
These settings are primarily consulted while Sandboxie prepares, filters, or creates a process token. Changing them does not retroactively rebuild an already assigned primary token. Restart affected sandboxed processes after changing the settings; recreating the sandboxed process tree provides consistent behavior. A SandMan, service, or driver restart is not normally required.
UnfilteredToken is also consulted during relevant later impersonation-token handling, but this does not remove the need to restart processes when changing primary-token policy.
The CopyDeviceGroups decision is evaluated when modern token construction is reached, including relevant later impersonation-token handling; it is not a separate process-start-only cache. A later configuration read does not rebuild an existing primary token.
Failure behavior
Essential token-filtering, construction, or assignment failures cause process initialization to fail rather than deliberately falling back to a less-restricted host token. Exact errors depend on the failed operation.
Optional CopyDeviceGroups retrieval failures are different: an unavailable source-token handle, failed information queries, or allocation failure can leave construction to continue without the optional device-group information. This does not guarantee that token creation or assignment will succeed, and a constructor failure does not automatically trigger a retry without device groups.
The optional CopyTokenAttributes step is different: failure to copy TokenSecurityAttributes does not invalidate an otherwise successfully created token.
Version history
- UnfilteredToken and UnrestrictedToken date to Sandboxie Plus 0.2.1 / Classic 5.41.1.
- KeepTokenIntegrity dates to Sandboxie Plus 0.3.0 / Classic 5.42.
- KeepUserGroup and UnstrippedToken date to Sandboxie Plus 1.0.6 / Classic 5.55.6.
- The setting metadata records NoUntrustedToken, ReplicateToken, and CopyTokenAttributes as added in Sandboxie Plus 1.14.1.
- CopyDeviceGroups was introduced in Sandboxie Plus 1.17.0 / Classic 5.72.0.
- The dedicated NoUntrustedToken SandMan control was documented in the Sandboxie Plus 1.17.0 / Classic 5.72.0-era changes.