自定义权限依赖项令人讨厌的问题

Question

我有一个应用程序（我们称之为“L”），它提供了其他应用程序可以绑定的Service。 Service要求绑定客户端具有权限"my.permission"。

我有另一个应用程序（我们称之为“X”），它使用“L”中的Service。在“X”的清单中，我有：

<uses-permission android:name="my.permission"/>

现在我在Android 4.4（Kitkat）上有以下不同的场景：

1. 用户安装第一个应用程序“L”，然后安装应用程序“X”。用户运行应用程序“X”。 “X”成功绑定到“L”中的Service。客户很高兴。
2. 用户安装第一个应用程序“X”，然后安装应用程序“L”。用户运行应用程序“X”。由于安全性异常，“X”无法绑定到“L”中的Service。 Android声称应用“X”没有所需的权限“my.permission”。顾客很生气。

经过大量实验后发现，在第二种情况下，当用户安装应用“X”时，Android会在清单中看到权限请求，但对权限"my.permission"一无所知，所以它拒绝授予app“X”这个权限。解决此问题的唯一方法是卸载应用程序“X”并再次安装。此时，由于已经安装了应用“L”，因此Android知道该权限并授予应用“X”的权限。

经过更多实验，我想出了解决问题的方法。我将以下内容添加到app“X”的清单中：

<permission android:name="my.permission/>

现在，当我安装第一个应用程序“X”时，Android知道该权限（因为它在清单中声明）并授予该应用程序的权限。客户很高兴。

一段时间后......

现在我在Android 5.0（Lollipop）上有以下场景：

1. 用户安装第一个应用程序“L”，然后安装应用程序“X”。由于INSTALL_FAILED_DUPLICATE_PERMISSION，Android拒绝安装应用“X”。顾客很生气！
2. 用户安装第一个应用程序“X”，然后安装应用程序“L”。由于INSTALL_FAILED_DUPLICATE_PERMISSION，Android拒绝安装应用“L”。顾客很生气！

要解决此问题，我现在从应用“X”中删除<permission>声明，然后在Android 5.0上再次尝试安装scenarious。我现在遇到与4.4完全相同的问题。

我发现让这个工作的唯一方法是强制用户在app“X”之前安装app“L”。顾客不高兴。

有什么想法吗？

Answer 1

  

现在，当我安装第一个应用程序“X”时，Android知道该权限（因为它在清单中声明）并授予该应用程序的权限。客户很高兴。

不幸的是，这也是一个重大的安全漏洞，如any app can do the same thing。自定义权限主要用于固件/预安装的应用程序。

  

有什么想法吗？

最重要的是使用相同的签名密钥对L和X进行签名。在这种情况下，它们可以具有相同的<permission>元素。但是，我假设他们没有被相同的密钥签名，否则你不会发布这个问题。

我所知道的唯一其他选择是不通过自定义权限保护，而是使用其他安全措施。在L's onBind()中，您应该能够使用getCallingUid()来查看来电者是谁。通过包名称和signature check验证X是调用者。如果可能有多个应用程序填充X的角色，您将最终使用L包名称/签名哈希对中的白名单进行检查。