Permission enforcement s in android new (1)
Download as PPT, PDF2 likes1,760 views
This document provides an overview of the Android permission system. It discusses how Android uses a permission model to control access to system resources and protect user privacy and security. Permissions are categorized as normal, dangerous, or signature/system level. The document outlines how permissions are declared in manifest files and enforced at both install-time and runtime via checks by the package manager. It also describes how permissions relate to application sandboxing using Linux users and groups, and how they are checked for various app components like activities, services, and broadcasts.
Permission enforcement s in android new (1)
- 1. A tour on Android Permissions Chadalawada Venkata Satheesh Piduri Siddharth Kakarla
- 3. IntroductionIntroduction A central design point of the Android security architecture is that no application, by default, has permission to perform any operations that would adversely impact other applications, the operating system, or the user.
- 4. Permissions classificationPermissions classification Android controls access to system resources with install-time permissions. In Android permissions are categorized into three threat levels: 1.NORMAL -Basic 2.DANGEROUS - Related to spending money, private info 3.SIGNATURE / SYSTEM - control backup’s, delete packages etc.. NORMAL Eg: SET_WALL_PAPER DANGEROUS Eg: TOGGLE_WIFI SIGNATURE / SYSTEM Eg: DELETE_PACKAGE
- 5. Sandboxing in AndroidSandboxing in Android •Linux Kernel is responsible for app sandboxing •Each Application runs in a separate process isolating it from other applications •Resource sharing is facilitated between applications through permissions Com.far.app3 (app_93 Com.bar.app2 (app_82) Com.foo.app1 (app_41) Kernel Dalvik VM App Dex Code Shared Libs App/JNI System HAL
- 6. Permission DeclarationsPermission Declarations •<user-permission> : Declare the permissions that your application needs •<permission> : To enforce own permissions •android:permission : Permissions that the application needs For example, an application that needs to monitor incoming SMS messages: <manifest xmlns:android=“http://schemas.android.com/apk/res/android” package=“com.android.app.myapp”> <uses-permission android:name=“android.permission.RECEIVE_SMS”/> ... .. </manifest>
- 7. Permission Enforcement in KernelPermission Enforcement in Kernel - UID, GID- UID, GID UID: A Unique identification number given to each application by kernel. AID_ROOT 0 /* traditional unix root user */ AID_SYSTEM 1000 /* system server */ AID_RADIO 1001 /* telephony subsystem, RIL */ AID_BLUETOOTH 1002 /* bluetooth subsystem */ AID_GRAPHICS 1003 /* graphics devices */ AID_INPUT 1004 /* input devices */ GID: A unique identification number given to a group of applications by kernel /* The 3000 series are intended for use as supplemental group id's only. */ /* They indicate special Android capabilities that the kernel is aware of. */ AID_NET_BT_ADMIN 3001 /* bluetooth: create any socket */ AID_NET_BT 3002 /* bluetooth: create sco, rfcomm or l2cap sockets */ AID_INET 3003 /* can create AF_INET and AF_INET6 sockets */ AID_NET_RAW 3004 /* can create raw INET sockets */
- 8. Kernel permission enforcement –Kernel permission enforcement – GroupID’sGroupID’s
- 10. How Zygote sets UID’s and GID’sHow Zygote sets UID’s and GID’s Before the app runs, the spawning process zygote uses standard UNIX system calls to set its UID and GID
- 11. Tracing - SnapshotsTracing - Snapshots
- 12. Contd..Contd..
- 13. Occurrences of PermissionOccurrences of Permission EnforcementEnforcement At the time of a call into the system. When starting an activity Both sending and receiving broadcasts. When accessing and operating on a content provider. Binding to or starting a service. To prevent an application from executing certain functions. To prevent applications from launching activities of other applications. To control who can receive your broadcast or who can send a broadcast to you. To grant the RW access of DB to permitted Whether it can use the service or not
- 15. Permission checking at componentsPermission checking at components Activity: Context.startActivity() Activity.startActivityForResult() ~~SecurityException Service: Context.startService() Context.stopService() Context.bindService() ~~SecurityException BroadcastReceiver: Context.sendBroadcast() ~~ No Intent delivery ContentProvider: Android:readPermission ContentResolver.query() Android:writePermission ContentResolver.insert() ContentResolver.update() ContentResolver.delete() Others: Context.checkCallingPermission() When PID: Context.checkPermission(Permission_ name,pid,gid)
- 16. URI PermissionsURI Permissions Grant the receiving activity permission access the specific data URI in the Intent, regardless of any permission to access data in the content provider Eg: Image viewing in Email attachment Intent.FLAG_GRANT_READ_URI_P ERMISSION Intent.FLAG_GRANT_WRITE_URI_P ERMISSION Mechanism allows a common capability-style model where the user interaction drives adhoc granting of permissions Android:grantUriPermissions()
- 18. Permission Acceptation at Install-TimePermission Acceptation at Install-Time
- 19. Contd..Contd.. public void grantPermission(String packageName, String permissionName) { mContext.enforceCallingOrSelfPermission( android.Manifest.permission.GRANT_REVOKE_P ERMISSIONS, null); synchronized (mPackages) { final PackageParser.Package pkg = mPackages.get(packageName); if (pkg == null) { throw new IllegalArgumentException("Unknown package: " + packageName); } final BasePermission bp = mSettings.mPermissions.get(permissionName) ; if (bp == null) { throw new IllegalArgumentException("Unknown permission: " + permissionName); } checkGrantRevokePermissions(pkg, bp); final PackageSetting ps = (PackageSetting) pkg.mExtras; if (ps == null) { return; } final GrantedPermissions gp = (ps.sharedUser != null) ? ps.sharedUser : ps; if (gp.grantedPermissions.add(permissionN ame)) { if (ps.haveGids) { gp.gids = appendInts(gp.gids, bp.gids); } mSettings.writeLPr(); } } }
- 20. Runtime Permissions APIRuntime Permissions API Android provides APIs to check, enforce, grant, and revoke permissions at runtime. These APIs are part of the android.content.Context class. For example, if you want to handle permissions gracefully, you can determine whether your application has been granted access to the Internet if (context.checkCallingOrSe lfPermission(Manifest.per mission.INTERNET) != PackageManager.PERMISSION _GRANTED) { // The Application requires permission to access the // Internet"); } else { // OK to access the Internet }
- 21. Contd..Contd.. components Activities Services ….. Application Context -check permission() -chackCallingPermission() IActivityManager Binder + Parcel permission PID UID Activity Manager Native Activity Manager Service Root? Yes No Package Manager Service checkComponentPermission() checkUidPermission() checkPermission() pid p.n 01 aa 02 bb 03 cc p.n g.p aa I,B ,P bb B,I cc B Has Nam e? Access Manager •If perms associated with intents? •Calling compon has granted with perm associated with intent? IPC mechanism for Android Parcel-generic buffer – interproc mesgs permission PID UID Extrats the parcel +resp call for perm checkCompoPer() No Denied Yes
- 22. Contd..Contd.. public int checkPermission(String permName, String pkgName) { synchronized (mPackages) { PackageParser.Package p = mPackages.get(pkgName); if (p != null && p.mExtras != null) { PackageSetting ps = (PackageSetting)p.mExtras; if (ps.sharedUser != null) { if (ps.sharedUser.grantedPermi ssions.contains(permName)) { re turn PackageManager.PERMISSION_G RANTED; }} else if (ps.grantedPermissions.cont ains(permName)) { return PackageManager.PERMISSION_G RANTED; }}} return PackageManager.PERMISSION_D ENIED; }