Proposal: Easing and streamlining named object sharing between packaged and Win32

[DefaultRyan]

Easing and streamlining named object sharing between packaged and Win32

This is a proposal for a flat C API that takes a list of Package Family Names (PFNs) and an access mask, and returns a security descriptor

Background

~~Named objects (mutexes, events, waitable timers) created by packaged applications must be ACLed during creation in order to be shared outside the package.~~

Named objects (mutexes, events, waitable timers) must be ACLed during creation in order to be shared with packaged applications.

Currently, our guidance for this scenario is to write a large amount of complex, cumbersome, and largely boilerplate code. (See here for a taste).

If we are to meet developers where they are, we need to reduce the friction of Win32 and UWP interop, and make it as easy as possible to share named objects.

Description

Add a flat C API that takes an array of PFNs and an access mask, and produces the needed SECURITY_ATTRIBUTES struct needed by Create* APIs would address the most common scenarios and abstract away the complexity of building a security descriptor.

STDAPI GetSecurityDescriptorForPackageFamilyNames(
    DWORD                 cCountOfPackageFamilyNames,
    const PCWSTR*        pListOfPackageFamilyNames,
    DWORD                 accessMask,
    SECURITY_DESCRIPTOR** ppSD
)

Open questions

C# API

Is there any alternative to using PInvoke for this API?

WinRT API

I can't think of a good way to represent the resulting PSECURITY_DESCRIPTOR in the WinRT type system, and I'm not seeing any immediate value to providing an implementation of this in WinRT.

[jaigak]

@DefaultRyan Why not represent PSECURITY_DESCRIPTOR as a WinRT class?

[smaillet-ms]

This seems reasonable with a few syntactical updates:

1. Don't use LPCWSTR, just use PCWSTR
2. Don't use the "P" prefixed typedefs unless absolutely necessary, they are confusing with respect to const/volatile qualifiers (e.g. the result isn't intuitively obvious)

I wonder if it's a bit too "simplified" though. Are there other ACE entries one might need or want? Should all packages listed, always get the same rights? What if I wanted to control the rights per package?

[smaillet-ms]

RE P/Invoke. What's the concern with that? .NET already has a rich model for manipulating security descriptors. If we wanted to have an official WinRT way of doing that it would be good to model things on that. However, I don't see this as something that comes up often enough to warrant such a major effort.

[DefaultRyan]

@Jaiganeshkumaran

@DefaultRyan Why not represent PSECURITY_DESCRIPTOR as a WinRT class?

I don't see a WinRT class for this adding much value. There aren't WinRT APIs for creating named shareable objects. C/C++ consumers simply use the Win32 APIs CreateMutex, CreateEvent, etc, which are already available to UWP apps. C# consumers already have their own model for security descriptors.

[DrusTheAxe]

Why a list of PackageFamilyName? Are PackageSIDs the only thing folks need to grant access? The background section says ... in order to be shared outside the package., it doesn't say only needing to share with other packaged apps. If that's really the goal then the Background section should be revised

This provides 1 accessmask. No need to grant different rights to different PackageSIDs?

[DefaultRyan]

@smaillet-ms Happy to make the syntax updates. Regarding different rights per package, we already have APIs to grant specific access to individual apps. It's somewhat cumbersome, but can be done. Do you think this API would be more useful if it instead took an array of access masks, to match each one to the target app?

Also, no "concern" with P/Invoke. Not a C# expert, so I don't know of P/Invoke is reviled for its complexity - just wondering if there's any need to streamline it and provide interop with its existing security functionality. If it's already "accepted" in the C# community that P/Invoke is the way to use cross-process named objects, then I'll agree we don't need to address anything there.

[DefaultRyan]

@DrusTheAxe PackageSIDs aren't the only thing folks need to grant access. We already have lots of APIs for this - this is about trying to provide a simplified happy path for common scenarios. Presumably, Project Reunion is going to drive increased interop between Win32 and UWP apps, and this proposal simply tries to simplify the most common cases. Developers can always fall back to the more complicated way of doing this if they need more specific functionality. See my earlier question about changing the single access mask with an array of access masks, to match each app?

[DefaultRyan]

Adding @mikebattista to the discussion.

[stevewri]

Are you looking for something beyond what is possible with Sidecars today? If we were to create an open-ended mechanism for sharing objects between UWP apps running in app containers and Win32 apps running as medium IL, there are any number of elevation of privilege concerns we'd have to review and mitigate.

[DefaultRyan]

This proposal addresses functionality that is currently available through existing APIs, but it's a pretty cumbersome and complex pile of code (see here), and it's easy to get wrong. Just trying to provide one or more helper methods in a library so developers can more easily accomplish this task.

So we're not creating any new mechanisms, just allowing devs to get to existing mechanism using less error-prone code,

I've never heard of Sidecars. What does that do?

[DefaultRyan]

One other thought I had:

This isn't exactly new functionality - it's putting an easier-to-use layer on top of existing functionality. Perhaps this is functionality that would be an appropriate addition to WIL, instead?

[DrusTheAxe]

WIL is a C++ library. Is this needed in other languages? C# and Rust come to mind. For a start :-)

[DrusTheAxe]

I've never heard of Sidecars. What does that do?

It's an old term for a 'helper' or 'sidekick'.

For example, MSIX added support for DesktopBridge applications in 10.0.14393.0 (aka Anniversary Update aka Redstone 1), however not all functionality was available to them. For instance, ShareTarget required a Universal app, and due to an unfortunate implementation detail you couldn't do

<Application EntryPoint="Windows.FullTrustApplication"...>
    <Extensions>
         <Extension Category="windows.shareTarget" EntryPoint="Foo.Bar"...>

because activating the ShareTarget extension should have used the extension's activation info but, if the parent <Application> was a DesktopBridge application the app's activation info was used i.e. the ShareTarget extension here would be activated using the <Application>'s info thus as a DesktopBridge app. Which doesn't work as Windows' ShareTarget support requires a Universal app to interact with.

But, you could do this with a sidecar application

<Application EntryPoint="Windows.FullTrustApplication"...>...</Application>
<Application Entrypoint="Foo.Sidecar.App.Not.Meant.To.Be.Run"...>
    <Extensions>
         <Extension Category="windows.shareTarget" EntryPoint="Foo.Bar"...>

NOTE: This implementation detail was (mostly) addressed in 10.0.19041.0 (aka May 2020 Update aka 20H1) so you can now do the former for ShareTarget (and many other extensions, though not all. Yet :P). No need for a 'sidecar' app anymore, for ShareTarget.

For another example, some Windows functionality was only available to packaged applications e.g. ShareTarget. Non-packaged applications couldn't do it. One solution is a sidecar package, where your application has a helper packaged app in an MSIX package. Windows calls your packaged app, which then does the functionality, or even does some form of IPC to your (non-packaged) app to do your heavy lifting. In this case the sidecar package is a helper to provide access to functionality your non-packaged app can't directly access. This is one of the scenarios that benefits from simpler security APIs like the proposed GetSecurityDescriptorForPackageFamilyNames :-)

NOTE: This became easier for many in 10.0.19041.0 (aka May 2020 Update aka 20H1) with support for sparse package where you can provide an MSIX package that's really just a manifest with uap10:AllowExternalContent with no content. When you install the package you provide an external location pointing to your content (e.g. C:\Program Files\Foo).

Project Reunion's Dynamic Dependencies spec mentions a "per-application 'helper' Main package". Another term for that would be a sidecar package.

NOTE: Several scenarios Project Reunion's targeting or considering need a sidecar package, as a means to leverage existing Windows functionality to our ends (i.e. without changing previously released versions of Windows). We're discussing ways to simplify making such sidecar packages. Ideally a COM like experience -- developer writes a text file with some data, runs it through a tool that generates some files you include in your build process and voila! Magic happens. Watch the Issues list for an upcoming proposal.

[DefaultRyan]

WIL is a C++ library. Is this needed in other languages? C# and Rust come to mind. For a start :-)

Excellent point, particularly on Rust. Here comes the spec... :)

[mominshaikhdevs]

I believe, It's completed by Dynamic Dependencies.

A WinRT API will come in handy for easier consumptions from programming languages, other than only C | C++ | C#.

Distantly Related Issues:

• https://github.com/microsoft/WindowsAppSDK/discussions/5250#discussioncomment-12649261.

• https://github.com/microsoft/microsoft-ui-xaml/issues/7690.

• https://github.com/microsoft/sudo/issues/7.

• https://github.com/microsoft/WindowsAppSDK/issues/5258#issue-2938316749.

• https://github.com/microsoft/WindowsAppSDK/issues/8.

• https://github.com/microsoft/WindowsAppSDK/issues/219.