Android Secure Access Mechanism

Overview:

Android is a multi-process system in which applications (or part of the system) run in their own processes. Security between systems and applications is enforced at the process level by Linux facilities (tools and functions). For example, user ID and group ID are assigned to the application. The more detailed security feature is to restrict specific operations of a specific process through the "permission" mechanism, "Per-Uri Permissions" can restrict the access permissions for specific data. Therefore, applications generally cannot access each other, but anroid provides a permission mechanism for secure access to data and functions between applications.

I. Security Architecture

In the android security architecture, the central idea is that applications cannot perform any operations that negatively affect other applications, systems, or users by default. This includes reading or writing users' private data (such as contact data or email data), reading or writing files of another application, network connection, and keeping the device sleep.

The process of an application is a secure sandbox. It cannot interfere with other applications unless "permissions" is explicitly stated so that it can obtain additional capabilities not available in basic sandboxes. The permission "permissions" requested by it can be processed by various operations, such as automatically allowing this permission or disabling this permission through user prompts or certificates. The "permissions" required by the application is declared statically in the program, so they will be known during program installation and will not change.

All Android applications (. The private key of the certificate must be kept by the developer. This certificate can be used to identify the author of an application. This certificate does not require ca signature authentication (Note: Ca is a third-party certificate authority, such as Verisign ). Android applications allow and generally use self-signed certificates ). Certificates are used to establish trust relationships between applications, rather than to control whether programs can be installed. The most important way to affect the security of signatures is to decide who can access signature-based permisssions and who can share user IDs.

Ii. user IDs and File Access

Every Android Application (. APK file) will be assigned a unique Linux User ID during installation, which creates a sandbox for it, make it inaccessible to other applications (and do not expose other applications to it ). This user ID will be assigned to it during installation and keep the same value on the device.
Because security restrictions occur at the process level, the code in the two packages will not run in the same process. They will appear as different Linux users. We can use androidmanifest. The shareduserid attribute in the manifest label in the XML file, so that different packages share the same user ID. In this way, the two packages are considered to be the same application, have the same user ID (not necessarily), and have the same file access permissions. Note: To ensure security, the same user ID is assigned only when two applications are signed by the same signature (and the same shareduserid is requested.

All data stored in the application is assigned a property-the user ID of the application, which makes other packages unable to access the data. When using these methods, getsharedpreferences (string, INT), openfileoutput (string, INT), or openorcreatedatabase (string, Int, sqlitedatabase. cursorfactory) to create a new file, you can use the mode_world_readable and/or mode_world_writeable flag to set whether to allow other packages to access and read the file. When these flags are set, the file still belongs to the application,
However, its global read and/or write permission has been set to make it visible to any other application.

For example, if both apk a and apk B are products of Company C, you can log in from APK a successfully. You do not need to log in again when you open apk B. The specific implementation is to set a and B to the same user ID:

Androidmanifest of packagename apk:

<Manifest xmlns: Android = "http: // schemas. Android. COM/APK/RES/android "package =" com. Android. Demo. A1 "Android: shareduserid =" com. c ">

Androidmanifest of packagename apk:

<Manifest xmlns: Android = "http: // schemas. Android. COM/APK/RES/android "package =" com. Android. Demo. B1 "Android: shareduserid =" com. c ">

This "com. c" is the user ID. Apk B can open the database in APK a just like opening the local database. APK a stores the login information in a's data directory. When apk B starts every time, it reads the database below APK A to determine whether it has been logged in:

In apk B, the packagecontext OF A can be obtained through the package name of:

Friendcontext = This. createpackagecontext ("com. Android. Demo. A1", context, context_ignore_security );