以编程方式更改 Manifest - Android 自定义权限答案

【问题标题】：Programmatically alter Manifest - Android custom permissions以编程方式更改 Manifest - Android 自定义权限
【发布时间】：2013-09-02 12:19:57
【问题描述】：

当前Android Permission System causes the following issue：

App A 定义的自定义权限：

com.package.permission.READ_APP_DATA

当应用 B 安装声明自定义权限时，它被授予。

但是，如果应用 A 在应用 B 之后安装，则权限不授予应用 B。

虽然这可能不常见，但由于应用 B 通常是应用 A 的插件，它当然会发生并且对我的应用程序有效。

SuperUser 应用程序同意引入android.permission.ACCESS_SUPERUSER 的全局自定义权限，如果用户决定切换 SuperUser 应用程序，这可能是一个大问题。

为了处理这个问题，我打算在我的应用程序中使用以下代码来获得我即将开始声明的自定义权限：

checkPermissions(this, getCallingActivity().getPackageName()); // get the package name from the sender first

private boolean checkPermissions(Context context, String callingPackage) {

    final List<PackageInfo> apps = context.getPackageManager().getInstalledPackages(PackageManager.GET_PERMISSIONS);

    for (PackageInfo pi : apps) {

        if (pi.packageName.equals(callingPackage)) {

            String[] permissions = pi.requestedPermissions;

            if (permissions != null) {
                for (String permission : permissions) {
                    if (permission.equals("com.package.permission.READ_APP_DATA")) {
                        return true;
                    }
                }
            }
        }
    }
    return false;

根据这个问题的标题：这种方法“安全”吗？或者是否有一种方法/root-hack 可以在安装应用程序清单并将权限以编程方式“添加”到应用程序 B 后对其进行更改？

【问题讨论】：

"但是，如果应用 A 是在应用 B 之后安装的，则权限不会授予应用 B。" -- 在两个应用程序中具有相同的<permission> 元素，特别是如果这是signature 级别的权限。
“我相信这已经是我正在做的事情”——您的问题表明只有 App A 有一个 <permission> 元素，而 App B 只有一个 <uses-permission> 元素。我是说要将<permission> 元素也添加到App B，这样安装顺序就不再重要了。
“虽然要求 3rd 方开发人员以这种方式声明我的自定义权限，但感觉有点令人不安” - 正如我所指出的，最好使用 signature 级别的权限，因此所有受影响的应用程序都是您的。权限系统的一个不幸限制是，首先进入的人可以定义对用户（标签和描述）的权限。不过，您对此无能为力。
关于您上面的技术，我从未见过有人这样做。事实上，我最初的反应是它不起作用，直到我意识到requestedPermissions 确实包括非授权的。鉴于此，我没有看到任何漏洞，但我认为我有同样的恐惧，导致你发布这个问题。 :-) 如果不出意外，请确保您一直测试到您的 minSdkVersion，因为这感觉就像多年来 Android 的行为可能发生变化的那些领域之一。
在两个应用程序中声明自定义权限在 Android L 上不再起作用（您会收到安装错误：INSTALL_FAILED_DUPLICATE_PERMISSION）。他们似乎已经堵住了这个漏洞（另见commonsware.com/blog/2014/02/12/…）

标签： android permissions android-manifest

【解决方案1】：

我不确定我的问题是否正确，因为我不知道在安装后将权限侵入清单如何连接到您在上面发布的代码。但要回答你的最后一段：

不容易。用户必须在他的设备上安装一个 mod，它可以在应用程序请求它们时即时授予任意权限。 IIRC 清单文件本身仅在安装时解析。

所以我们在 mod 中使用的是改变类 grantPermissionsLPw 中的方法 com.android.server.pm.PackageManagerService。

它用于授予启动器权限android.permission.EXPAND_STATUS_BAR，它没有在其清单中声明。

但我不确定这是否会用于您的应用程序。但总结一下：如果用户想授予应用程序任意权限，自定义权限：是的，这是可能的。

更新

当然，我可以详细说明。我可以看到两种情况发生

1.静态模组

上述类位于services.jar。众所周知，像这样的文件可以被反编译、更改和重新编译。实际上，对这个文件进行相当简单的编辑。我不知道直接在电话上执行此操作的方法，但我认为这是可能的。只是不那么可行，因为它需要大量的处理能力，所以可以使用广泛的解决方案。攻击者不能只提供通用文件。这些文件因设备而异，也因固件版本而异。要么，攻击者需要提供大量修补文件，要么通过将其上传到服务器、修补、重新下载和安装来实时修补。如果你问我，这种情况不太可能发生。

2。动态模组

有不止一个框架可用，它们允许在进程运行时更改进程。其中最受欢迎的是Xposed Framework。基本上，它是一个修补过的app_process 和一个利用Reflection 来改变正在运行的进程的相应API。现在攻击者可以使用这个框架发布他的应用程序，并拥有 root 访问权限，静默安装它。有了root权限，他甚至可以自己启用模块，这通常需要用户交互。一旦启用了这样的模块，攻击者就可以挂钩上述方法并更改请求的权限。他将通过获取包含请求的权限的对象字段来执行此操作，添加他需要的那个，然后运行原始方法，该方法添加了最初定义的权限。

请注意，这两种情况都需要用户自己安装恶意应用。您没有提及您的应用程序的用途，因此我无法真正帮助您评估风险。我只能说，攻击者可以做这样的事情。

【讨论】：

感谢您的回答 - 您能否详细说明该模组的工作原理？这将帮助我理解“风险”。
请参阅上面的更新。也更正了类名。如果您还有其他问题，请随时提问。
感谢您的更新，它真的很有帮助，并且有一些很好的链接阅读。我会回来将您的答案标记为正确，并奖励您的努力。

【解决方案2】：

我确实看到了一个问题，即如果在应用 B 之前安装了应用 A，并且未在应用 A 中声明 <permission> 元素，则用户将永远不会看到权限请求。但是，如果您确实需要在 App A 中使用 <permission> 元素，则可以使用类似的方法来验证向用户显示的标签和描述是否准确。

【讨论】：