A recent conversation started (as many interesting conversations do) with a simple question:"Why is MSIX secure?"MSIX includes multiple layers of protection designed to defend against both accidental damage and malicious tampering. But as with all good security solutions, it's not the individual elements so much as their interlocking design that makes the whole stronger than the sum of its parts.MSIX was designed around several core facets, integrated in sometimes novel ways.A packaged process can be trusted to a higher degree than most applications because Windows maintains a verifiable chain of trust from the running process back to the developer's original signed package. Package identity, package signing, deployment validation, and runtime protections all work together to ensure that the package launched today is the same package the developer intended to ship.Package Identity in the Process TokenA packaged process has package identity etched into its process token when the process is created. This identity is stored in the token's WIN://SYSAPPID attribute, as can be seen by dumping the token in WinDbg via the !token command:...Security Attributes Information: 00 Attribute Name: WIN://SYSAPPID Value Type : TOKEN_SECURITY_ATTRIBUTE_TYPE_STRING Value[0] : Microsoft.WindowsTerminal_1.24.11911.0_x64__8wekyb3d8bbwe Value[1] : App Value[2] : Microsoft.WindowsTerminal_8wekyb3d8bbwe... This information is read via various APIs (e.g. GetPackageFullName()) but only Windows can write it (and only select code paths at that). This protects the package identity from modification at runtime.1Chain of TrustThe token's WIN://SYSAPPID attribute is crafted from the package's element in its AppxManifest.xml, forming a verifiable chain of trust back through install to the developer's original signed package.Running process ↓Package identity in token ↓AppxManifest.xml ↓AppxBlockMap.xml ↓Package signature ↓Developer certificatePackage identity in the token is trusted because Windows controls how it is stored and which code paths are allowed to write it.That identity originates from the package's AppxManifest.xml.The manifest is protected by the package's AppxBlockMap.xml. The block map contains hashes for every file in the package, including the manifest itself. If the manifest is modified after the package is built, its hash no longer matches the value recorded in the block map.The block map in turn is protected by the package signature (AppxSignature.p7x). Because the block map contains hashes of the package files, signing the block map indirectly protects the package contents as well. As a result, an attacker cannot modify either the manifest or the block map without invalidating the package signature.Before a package is installed, Windows validates the package signature and verifies the integrity information contained in the package.2 This validation establishes that:The signing certificate is trusted according to the system's certificate policy.The block map has not been modified since the package was signed.The manifest matches the hash recorded in the block map.If any of these validations fail, the package is considered tampered with and deployment rejects it. The deployment engine only installs packages that successfully complete validation.Package Integrity Content EnforcementThe chain of trust described above establishes that a package was authentic and unmodified when it was installed. But what protects that package after installation?Package Integrity Content Enforcement (PICE) helps preserve that trust by preventing unauthorized modification of package content on disk. Even if an attacker gains administrative rights, additional safeguards ensure that protected package files cannot be altered without using appropriately trusted Windows components.Windows stores a package's files in a package directory (aka pkgdir). A pkgdir has its access control list (ACL) written by Deployment when the package is Staged, restricting write access to LocalSystem and TrustedInstaller (i.e. Windows' setup). This is further locked down if the package is protected by PICE.All Store-signed packages are given this protection. Other signed packages can opt in to this protection by requesting enforcement in their AppxManifest.xml: Packages with this protection have their security descriptor extended with a Process Trust Label ACE (TL ACE). This additional restriction means that modifying package content requires not merely a protected process, but one running at an appropriate Windows trust level. This allows trusted Windows servicing components such as the Deployment engine to update package content while preventing less-trusted processes from altering it.PICE has been available to Store-signed packages since Windows 8.1. The manifest opt in was added in Windows 10 version 2004 (aka 20H1, aka 10.0.19041.0).Process Trust Label ACE (TL ACE)A Process Trust Label ACE is represented in SDDL as the ACE type string "TL". In practice, it's commonly referred to simply as the TL ACE. A TL ACE appears in the SACL portion of a security descriptor, e.g. S:(TL;;GR;;;S-1-19-...).This is reported by icacls when run from an admin prompt:[C:] icacls "C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.24.11911.0_x64__8wekyb3d8bbwe" ... S-1-19-512-4096:(OI)(CI)(RX,D,WDAC,WO,WA)Pervasive Package IdentifiersThis end-to-end chain of trust - from the running process all the way back to the developer's signed package - is unusual among application deployment technologies. Other installation technologies often have, at best, a verifiable link from installed artifacts on disk back to the developer's original distribution. Securely extending that trust relationship into runtime is comparatively rare.This approach was so novel that the USPTO awarded it patent number US-8990561-B2: Pervasive package identifiers.TL;DRQ: "Why is a process' package identity trustworthy?"A: "The process' package identity is stored as an attribute in its token."Q: "Why is that trusted?"A: "It comes from the manifest."Q: "Why is the manifest trusted?"A: "Its hash is in the block map."Q: "Why is the block map trusted?"A: "It's signed with the certificate as part of signing the package."Q: "Why is the signing trusted?"A: "Cryptography."1 Unless you have write access to kernel memory, but then you pwned the machine anyway and game over.2 Similar validation is also available through the AppX packaging APIs. For example, IAppxFactory::CreatePackageReader() validates package integrity information, including the package signature, block map, and manifest consistency, allowing applications to verify that a package has not been tampered with before consuming its contents.