'MATCH_UNINSTALLED_PACKAGES' flag exposes apps installed in other profiles without the proper permissions granted

[cohesive-flight]

I was discussing with the developer of App Manager in this issue about how his app was able to view packages installed in other profiles without being granted the proper permissions: INTERACT_ACROSS_USERS or MANAGE_USERS. The issue linked was initially only about packages installed within the work profile, but it does occur with user profiles as well.

In the documentation of the app, it's mentioned that this feature isn't properly supported in "no root" mode (without the use of ADB or root). However, it's still able to view packages installed in other profiles while in this mode. Albeit it's not able to view their details, as it thinks they're uninstalled, but it's still shouldn't be aware of their presence.

The developer believes this is due to the use of the MATCH_UNINSTALLED_PACKAGES flag. According to its android developer page, the flag:

"retrieve[s] some information about all applications (even uninstalled ones) which have data directories. This state could have resulted if applications have been deleted with flag DELETE_KEEP_DATA with a possibility of being replaced or reinstalled in future. Note: this flag may cause less information about currently installed applications to be returned."

Based on its note and my experience with it, it seems like it also returns installed applications within other profiles, bypassing the isolation they provide.

Device info

• Device: Pixel 7
• OS Version: Android 13
• Build Number: TD1A.220804.031.2022102800
• App Manager Version: 3.0.3 (414)
  • Mode: No Root

[muhomorr]

Only main ("Owner") profile is allowed to see apps installed in other profiles.
They are visible in Settings -> Apps, with "Not installed for this user" subtitle.

[muhomorr]

This information is accessible to user-installed apps on Owner profile only if Owner profile has a work profile:

https://cs.android.com/android/platform/superproject/+/android-13.0.0_r8:frameworks/base/services/core/java/com/android/server/pm/ComputerEngine.java;l=2856;drc=b45a2ea782074944f79fc388df20b06e01f265f7

// If the caller wants all packages and has a profile associated with it,
// then match all users. This is to make sure that launchers that need to access
//work
// profile apps don't start breaking. TODO: Remove this hack when launchers stop
//using
// MATCH_UNINSTALLED_PACKAGES to query apps in other profiles. b/31000380

Removing flags |= PackageManager.MATCH_ANY_USER there should be enough to fix this leak in user-installed Owner profile apps, but it will almost certainly break third-party launchers.

[cohesive-flight]

That seems odd. If a launcher needs access to all packages installed within the main and work profile for it to operate properly, why bother including user profiles? The launcher can't even be used there until it's installed.

I'm just going to assume they did not account for user profiles at all (unless they're not a thing in AOSP).

[muhomorr]

If a launcher needs access to all packages installed within the main and work profile for it to operate properly, why bother including user profiles?

There's no infrastructure for matching against the work profile in AOSP AFAIK, it's either current profile or all profiles (MATCH_ANY_USER). Wrong, see #1634 (comment)

Presence of TODO and a bug ID suggests that this'll be fixed in some way in the future.

[cohesive-flight]

I see.

It'd be worth noting this bug down in the user profile section of the GrapheneOS site until it's been addressed. As I'm sure there are others who also use a work profile for personal use, but aren't aware it compromises the isolation of their user profiles to a degree.

[muhomorr]

I've tested a build with this flags |= PackageManager.MATCH_ANY_USER statement removed.
Verified that it fixes this leak. Preinstalled launcher, Nova Launcher and Lawnchair all continue to work fine. Need to test with other launchers.

Update: Tested 20 launchers that came up in Play Store search for "launcher", none of them regressed with this build.

[muhomorr]

TODO: Remove this hack when launchers stop
//using
// MATCH_UNINSTALLED_PACKAGES to query apps in other profiles. b/31000380

This TODO has been added over 6 years ago, in October 2016:
https://android.googlesource.com/platform/frameworks/base/+/0d1fd8d09163566d2c7eb72037f63b6404ada642%5E%21/#F22

Commit message (scroll to the top of the page) says:

Secure MATCH_UNINSTALLED_PACKAGES across users

Introduce a new internal flag MATCH_ANY_USER for genuine uses
of searching through all apps on the device.

Some temporary accommodations for Launchers that reach across
to the work profile until we have a new LauncherApps API to do
that officially.

LauncherApps#getActivityList() API allows apps in Owner profile to see apps in its nested work profile, but not in other profiles.
Modern launchers are supposed to use it instead of MATCH_UNINSTALLED_PACKAGES flag.
This API is not limited to launchers however, any app can use it.

[cohesive-flight]

Update: Tested 20 launchers that came up in Play Store search for "launcher", none of them regressed with this build.

LauncherApps#getActivityList() API allows apps in Owner profile to see apps in its nested work profile, but not in other profiles.

I assume this means the developers simply forgot to remove this hack overtime? Since it looks like all modern launchers rely on the newer API instead.

[muhomorr]

I assume this means the developers simply forgot to remove this hack overtime

AOSP takes backward compatibility very seriously.