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

时间:2013-09-02 12:19:57

标签: android permissions android-manifest

当前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的权限?

2 个答案:

答案 0 :(得分:9)

我不确定我的问题是否正确,因为我不知道安装后如何通过黑客攻击清单连接到您上面发布的代码。但要回答你的最后一段:

不是一件容易的事。用户必须在他的设备上安装mod,它可以在应用程序请求时动态授予任意权限。 IIRC清单文件本身只是在安装时解析。

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

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

我不确定,如果这将用于您的应用程序。但总结一下:如果用户想要授予应用程序仲裁权,则自定义权限:是的,这是可能的。

<强>更新

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

<强> 1。静态模式

上述课程位于services.jar。我们知道,这样的文件可以被反编译,修改和重新编译。实际上,这个文件很容易编辑。我不知道直接在手机上这样做的方法,但我认为这是可能的。它不是那么可行,因为它需要大量的处理能力,因此可以使用广泛的解决方案。攻击者无法提供通用文件。这些文件在设备之间以及固件版本之间发生变化。或者,攻击者需要提供大量修补文件,或者通过将其上传到服务器,对其进行修补,重新下载和安装来实时修补。如果你问我,这种情况不太可能发生。

<强> 2。动态mod

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

请注意,这两种方案都要求用户自己安装恶意应用程序。你没有提到你的应用程序的用途,所以我无法在评估风险方面为你提供更多帮助。我只能说,攻击者可以做那样的事情。

答案 1 :(得分:0)

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