Does App Control -AppID enforce target-process checks for reused SEC_IMAGE sections?

Question

Does App Control -AppID enforce target-process checks for reused SEC_IMAGE sections?

Conner Durham 0

I am evaluating a supported process-specific executable-image boundary on Windows 11 Pro 24H2 x64. This is a design/support-contract question: I have not deployed the proposed policy or demonstrated a bypass. The application is a fixed native launcher embedding CPython 3.12 with third-party native dependencies. Microsoft-only Code Integrity Guard does not accommodate that dependency set. An ordinary loader notification alone would not satisfy the requirement. Proposed policy construction: - H is a finite, explicitly hash-allowed global image set in an enforced UMCI base policy. - P is the separately approved image subset for one fixed producer executable. - For every image in H but outside P, the same base includes a hash-based deny scoped to that producer with New-CIPolicyRule -AppID and -Deny. - Other applications may use H, but the producer must execute only P. Effective policy composition and updates would also have to preserve that boundary. The core question is whether Windows provides a supported complete-mediation contract for this construction: is application-scoped admission checked against the actual mapping target's application identity before an image outside P can execute there, including when its executable section was originally created or admitted in another allowed process? The relevant case is an image in H but outside P whose SEC_IMAGE section is already cached, named/reopened, inherited or transferred through a legitimately shared/duplicated section handle, then mapped into the producer. I also need to understand the initial process image and pre-entry dependency case. This is not a request for protection against a compromised kernel or administrator, and success of a non-executable SEC_IMAGE_NO_EXECUTE data mapping would not count as execution. I have read the per-app module rule examples, New-CIPolicyRule syntax, policy precedence/composition documentation, and the section-mapping APIs. They establish useful primitives, but I have not found a supported statement resolving the target-process check for all of those image-section routes. Could the App Control/Windows code-integrity team clarify whether this is a supported use of AppID-scoped rules, with a documentation reference for the exact application-identity match and enforcement point? Please identify any excluded route or version limitation. If the construction is unsupported, that clarification would be useful too. I am not asking for a policy deployment or a speculative workaround. References: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/use-appcontrol-policy-to-control-specific-plug-ins-add-ins-and-modules https://learn.microsoft.com/en-us/powershell/module/configci/new-cipolicyrule?view=windowsserver2025-ps https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/deploy-multiple-appcontrol-policies https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-zwmapviewofsection https://learn.microsoft.com/en-us/windows/win32/api/handleapi/nf-handleapi-duplicatehandle

Conner Durham 0 Reputation points

2026-10-29T00:26:08.62+00:00

Could a human moderator help route this to an App Control or Windows code-integrity specialist?

The AI response summarizes the documentation gap, but it does not establish whether this construction is supported or unsupported. I need clarification of destination-process enforcement for reused or transferred SEC_IMAGE sections, with a supporting Microsoft reference.

If this question is outside Q&A’s scope, please identify the appropriate support channel and whether it requires a paid support agreement.

2 answers

Your answer

Conner Durham 0 Reputation points

2026-10-29T00:26:08.62+00:00

Could a human moderator help route this to an App Control or Windows code-integrity specialist?

The AI response summarizes the documentation gap, but it does not establish whether this construction is supported or unsupported. I need clarification of destination-process enforcement for reused or transferred SEC_IMAGE sections, with a supporting Microsoft reference.

If this question is outside Q&A’s scope, please identify the appropriate support channel and whether it requires a paid support agreement.

Answer 1

Welcome to Microsoft Q&A!

Thank you for taking the time to share such detailed information.

Based on the currently published Microsoft documentation, I would not treat the proposed H/P construction as a documented complete process-specific executable-image security boundary for the SEC_IMAGE reuse scenarios you described.

1. What -AppID does document

Microsoft documents that App Control for Business can control whether specific plug-ins, add-ins, and modules run from specific applications. For example, New-CIPolicyRule -AppID can associate a module rule with a particular application, and -AppID together with -Deny can block a specified module from running in that application while allowing it to run elsewhere.

That establishes the supported application-specific policy behavior. The important distinction, however, is that the documentation does not describe the lower-level Code Integrity enforcement point needed to establish the stronger security boundary in your design.

Specifically, the documentation does not state that Code Integrity performs a new AppID evaluation against the destination process identity every time an executable SEC_IMAGE section is mapped, regardless of where or when that section was originally created, validated, or obtained.

2. Why the SEC_IMAGE distinction matters

This matters because Windows section objects are not limited to the ordinary DLL-loading path.

The ZwMapViewOfSection function documentation states that a section is mapped into the address space of the process identified by ProcessHandle. It also documents that ViewShare allows the view to be mapped into subsequently created child processes and that several views of the same section can be concurrently mapped into one or more processes. For SEC_IMAGE sections specifically, the requested Win32Protect value does not determine the mapped image's protection.

Similarly, DuplicateHandle function documents that a handle can be duplicated into another process and that the duplicate refers to the same underlying object as the original handle.

Those APIs therefore establish that section views and handles can cross process boundaries. However, they do not document an App Control or Code Integrity decision point. Conversely, the App Control documentation does not state whether an AppID rule is reevaluated against the destination application's identity when an already created or previously admitted image section reaches that process through a cached, reopened, inherited, or duplicated/transferred section path.

That is the specific documentation gap affecting this design.

The same caution applies to the initial executable image and dependencies mapped before application entry. The published per-application plug-in/module examples do not establish that broader enforcement guarantee, so I would not infer it from those examples alone.

3. Policy composition does not resolve this point

Multiple-policy behavior is documented separately.

Microsoft documents that when multiple base App Control policies are active, an application must satisfy all of the base policies to run. In other words, multiple base policies have intersection behavior. Supplemental policies instead expand their associated base policy.

That is relevant when maintaining the proposed H/P policy boundary, but it still does not establish when or against which process identity an AppID condition is evaluated for an already-existing executable image section.

4. What this means for the proposed H/P design

For this reason, I would treat -AppID as supported for the documented application-specific plug-in/module control scenario, but I would not represent it as a documented complete-mediation security boundary covering every SEC_IMAGE reuse or transfer path.

Importantly, this does not establish that any of the section-reuse paths you described bypass App Control. There is no basis in the cited documentation to make that claim either.

The distinction is simply that the available documentation does not provide the implementation-level guarantee necessary to prove the security invariant in either direction.

Likewise, successful testing on Windows 11 24H2 could establish the observed behavior of the tested Windows build and mapping path, but it would not by itself establish the Microsoft support contract you are asking about.

5. Regarding escalation to an App Control/Code Integrity specialist

I understand why you are asking whether a human moderator can route this to an App Control or Windows Code Integrity specialist. In this case, the remaining question is no longer about how to configure the documented App Control feature. It requires an authoritative statement about an internal Code Integrity enforcement contract that is not defined in the available public documentation.

Microsoft Q&A is primarily a community technical-support forum. It can help interpret documented product behavior and troubleshoot supported configurations, but it is not the appropriate channel for establishing an undocumented Windows kernel/Code Integrity implementation guarantee.

For that reason, the most appropriate next step is to open a Microsoft Support request for App Control/Code Integrity and ask for the case to be reviewed or escalated to the appropriate product specialist.

To keep the request focused, I recommend asking Microsoft Support to confirm these four points:

Whether an AppID-scoped rule is evaluated using the destination/target process identity for every executable SEC_IMAGE mapping.
Whether that evaluation occurs when an already created or previously admitted image section is cached, reopened, inherited, or supplied through a duplicated/transferred section handle.
Whether the same enforcement guarantee applies to the initial process image and pre-entry dependency mappings.
Whether there are any Windows-version or image-mapping-path exclusions from that guarantee.

Regarding whether this requires a paid support agreement, Microsoft Q&A cannot determine the support entitlement associated with your organization or account. The available support options depend on the Microsoft support plan or entitlement associated with that account and will be presented when the support request is created.

I appreciate that this is not the definitive product-team "supported" or "unsupported" statement you were hoping to obtain from the forum. However, because your requirement is specifically a security-boundary and support-contract guarantee, I do not want to speculate beyond what Microsoft currently documents. In this case, a Microsoft Support case is the appropriate path to obtain authoritative clarification from the relevant product specialists.

References:

Use an App Control for Business policy to control specific plug-ins, add-ins, and modules

New-CIPolicyRule

Use multiple App Control for Business policies

ZwMapViewOfSection

DuplicateHandle

I hope this helps clarify the distinction between the documented AppID policy capability and the stronger complete-mediation guarantee required by your design, as well as why the latter needs confirmation through Microsoft Support.

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.

Answer 2

The proposed -AppID deny construction cannot currently be treated as a publicly documented, supported complete-mediation boundary for reused SEC_IMAGE sections; obtain a written App Control product-group determination before relying on it as a security contract.

What Microsoft documents

New-CIPolicyRule -AppID creates per-app enforcement rules controlling whether specified plug-ins, add-ins, or modules can run from a specified application. Combining -AppID with -Deny is explicitly documented for blocking a module in one application while permitting it elsewhere.^1^ The cmdlet exposes -AppID only in its DriverFilePath parameter set and describes it in those same per-app terms.^2^

Per-app rules are available on Windows 11, and App Control for Business is supported on Windows Pro, so Windows 11 Pro 24H2 is within the documented platform and edition scope.^3^

However, the available documentation does not define:

How the application named by -AppID is identified at runtime.
Whether that identity is the creator, requesting process, destination process, initial process image, or another loader context.
The exact Code Integrity enforcement point.
Whether authorization is repeated whenever an executable image view is inserted into a destination process.
Whether an existing, cached, named, reopened, inherited, or duplicated SEC_IMAGE section is reauthorized for that destination.
Whether process creation covers the initial executable and all pre-entry dependency mappings under the same per-app rule semantics.
Any Windows 11 24H2-specific guarantee closing those routes.

Consequently, the documentation supports the ordinary per-app module-control scenario, but not the stronger conclusion that it forms a complete executable-image confinement boundary across every section-object route. This is an absence of a public guarantee—not evidence that the implementation necessarily omits the check.

Why the section APIs do not settle it

ZwMapViewOfSection explicitly maps a section into the address space identified by ProcessHandle, permits multiple views in multiple processes, and supports future child-process sharing through ViewShare. For SEC_IMAGE, the requested Win32Protect does not determine the image protections.^4^

DuplicateHandle makes the duplicate refer to the same underlying object as the original.^5^ Neither API contract states that App Control performs—or does not perform—a destination-process AppID evaluation when the executable view is mapped. Therefore, these API descriptions cannot establish the required mediation guarantee.

Policy composition does not close the gap

Your composition assumptions are otherwise aligned with documented policy behavior:

An explicit deny takes precedence over an explicit allow.^6^
With multiple base policies, an application must pass every base policy.
A supplemental policy expands its base policy, so base-plus-supplemental authorization is a union.^7^

Those rules explain file-rule outcomes once an evaluation occurs. They do not document whether each reused image-section mapping causes the destination-scoped evaluation your boundary requires.

Also, AppID per-app rules are not AppId Tagging policies. AppId Tagging adds metadata to qualifying process tokens and explicitly does not control whether applications run.^8^

Required escalation

Open a Microsoft Unified/Premier support case for App Control for Business on Windows 11 Pro 24H2 and request a product-group supportability determination. A concise case question is:

Does App Control New-CIPolicyRule -AppID -Deny authorize an executable image against the destination process’s application identity on every executable image-view insertion, including an existing or cached SEC_IMAGE section reached through reopening, naming, inheritance, section-handle duplication or transfer, and ViewShare? Does the same contract cover the initial process image and dependencies mapped before user-mode entry? Identify any excluded route, build dependency, or servicing limitation.

Audit-mode experiments and Code Integrity logs can characterize a particular build, but they cannot establish the servicing guarantee requested. App Control provides audit mode for policy-impact testing, and enforcement begins when that option is removed.^9^ Without an affirmative written determination covering these cases, this design should be classified as unsupported for the stated complete-mediation requirement, rather than as a demonstrated bypass.

References