Is there a way to store data restricted to a packaged app?

[mikehearn]

On macOS an app can store data that other apps can't access by (ab)using the password storage in the user's login keychain. The keychain service won't reveal the "password" (which can be a text encoded key) to other apps unless the user explicitly grants access, and that key can then be used to encrypt files on disk so they're not visible to other apps. Browsers use this to protect their cookie storage, for example.

It appears there's no way to do the same thing on Windows. There is the WinRT PasswordVault class which does link saved passwords to the appcontainer, but unpackaged apps can simply access all passwords instead of none as you might expect.

Is there a way to store data somewhere in Windows, via some technique, such that it's restricted to a particular package identity and the kernel will protect it as such? Maybe setting ACLs / appcontainer SIDs on a registry key? If not, it'd be nice if such an API was added. It really makes things a lot more secure, assuming of course that unpackaged apps simply subvert package identity by doing things like injecting code or controlling the address space of a packaged app.

[rocksdanister]

Try encrypting the file using ProtectedData class with optionalEntropy maybe?
https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.protecteddata?view=dotnet-plat-ext-7.0

[mikehearn]

DPAPI doesn't bind a secret to an app, as far as I understand, just a user. Any app can access the secrets of any other app if they run as the same user.

[rocksdanister]

Add optionalEntropy?

The optionalEntropy parameter enables you to add data to increase the complexity of the encryption; specify null for no additional complexity. If provided, this information must also be used when decrypting the data using the Unprotect method.

https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.protecteddata.protect?view=dotnet-plat-ext-7.0

[mikehearn]

I don't understand I'm afraid. That will mix in extra entropy but you'd still have to store it somewhere app private. Encryption is the easy part. The hard part is finding a place where you can stash data that the kernel will only hand out to apps with the correct package identity, in a non-spoofable way. This is what macOS can do. With MSIX apps on Windows can now have package identity in a similar way, but that doesn't seem to be plumbed through to the key store.

[sopelt]

The discussion at #1840 predates this one and struggles with the same use-case.

[jonwis]

We recently experimented with this ourselves for another purpose. You can create an ACL that has a "conditional ACE" in it that only allows access if the calling process is part of a package. See https://stackoverflow.com/questions/63455546/whats-exists-win-sysappid-condition-in-c-program-files-windowsapps-acl for an explanation of the mechanism.

I'll have to sanitize the code a little, but the mechanism was:

• Create an SDDL like "D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(XA;OICI;FA;;;" + userSidString + ";(WIN://SYSAPPID Contains " + packageFamilyName + "))"
• Use wil::get_token_information<TOKEN_USER>()->User.Sid and ConvertSidToStringSidW to get the userSidString above
• Use winrt::Package::Current().Id().FamilyName() to get the packageFamilyName above
• Use ConvertStringSecurityDescriptorToSecurityDescriptor to make a SECURITY_DESCRIPTOR out of that
• Use winrt::AppDataPaths::GetCurrent().LocalAppData() to get the path into your package's storage root
• Use CreateDirectory to create a new directory under there and apply the security descriptor above

This ensures that only your app can browse the files in that directory. Note, however, that the user still owns the folder - the user can replace/reset the ACL using icacls or File Explorer prompting "did you want access?" ... neither should be happening on a regular customer's machine, though.

We've had a bunch of conversations about how to achieve this "private app data protection" system. This is the best I've got so far, but we're working on it.

What are some scenarios you'd use this mechanism for?

[sopelt]

For us (and probably the initial reporter and many others) having a credential store scoped to the container is the use-case on top of our list. Keeping stuff like cryptographic key pairs would also be interesting (but given the size one could probably store that as a base64 PW as a fallback).

In the past (.NET 4.x) we were using DPAPI to protect some stuff similar to this but given the user-profile scope it doesn't help to limit visibility between apps and when the profile gets migrated keys break in unpleasant ways ...

[mikehearn]

@jonwis For use case see the complaints today about Signal storing e2e encrypted chats in plaintext on the user's machine (where any app can access it). On macOS apps can store credentials and files securely, such that other apps are blocked, which improves privacy a lot.

The scheme you propose sounds good but on Windows I think apps can inject code into each other's address spaces pretty easily, no? if the user can override the permissions using Explorer, what stops some bad app injecting code into Explorer in order to override the ACL?

[DarranRowe]

The scheme you propose sounds good but on Windows I think apps can inject code into each other's address spaces pretty easily, no?

To this statement in particular, all I will say is try researching it. That would be the best way to know for sure, no?
If your research doesn't include creator/owner rights, integrity levels, SeDebugPrivilege and appcontainers, then you haven't got a complete answer.

if the user can override the permissions using Explorer, what stops some bad app injecting code into Explorer in order to override the ACL?

Ironically, if a bad application is capable of injecting code into Explorer, then it is easier to just do it in the application itself. Even more ironically, depending on the type of user account, the bad applicaiton may have more access through its own process than Explorer.

[mikehearn]

Sure, I could dig up long forgotten Win32 knowledge and try to write a program that injects code into Explorer, but the last time I did stuff like that was in the 90s. The chances of getting it wrong and being uncertain whether it fails because of a bug or fails because of a security check is quite high. All I remember is that back then a ton of legit apps did this and so it was very hard to lock down Explorer due to backwards compatibility. It sounds like you're saying this has changed and modern Windows does stop apps doing this in a systematic way, so there aren't any known (architectural) backdoors that would allow an app to sneakily adjust or work around an app specific ACL? Could someone confirm that this is thought to be the case in practice?

I'm asking because we might want to expose this feature in an easier to use way to customers who use our app packaging software, which would improve security for many apps simultaneously. So I was hoping someone can just document what the exact security guarantees Windows offers currently are (ideally on both 10 and 11) when it comes to apps interfering with each other. Apple does this and it makes it much easier to understand what is and isn't supposed to work, and how to test that you didn't accidentally undermine the security system somehow.