Zhengyang Qu 1 Guanyu Guo 2 Zhengyue Shao 2 Vaibhav Rastogi 3 Yan Chen 1 Hao Chen 4 Wangjun Hong 1 1 1 Northwestern University 2 Zhejiang University 3 University of Wisconsin Madison ID: 732143
Download Presentation The PPT/PDF document "AppShield: Enabling Multi-entity Access ..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
AppShield: Enabling Multi-entity Access Control Cross Platforms for Mobile App Management
Zhengyang Qu1, Guanyu Guo2, Zhengyue Shao2, Vaibhav Rastogi3, Yan Chen1, Hao Chen4, Wangjun Hong1
1
1
Northwestern University
2
Zhejiang University
3
University of Wisconsin, Madison
4
University of California, DavisSlide2
Android OS dominance
2Mobile OS Market Share, by
dazeinfo.com Slide3
Android malware/spyware
3Slide4
Birth of bring-your-own-
device4Slide5
Policies required in BYOD
5Slide6
Outline
IntroductionMotivationSystem OverviewEvaluationConclusion6Slide7
Common deployment of MAM
Application rewritingMocana, AirWatchWork on all devices, NOT on all applicationsSDKGood, Citrix, AirWatchWork on all applications, extra developer supportOS ModificationAndroid for work on Android 5.0 and aboveDependencies on OS versions or customizationLimitation of portability
7Slide8
Android segmentation
8Android OS distribution snapshot in March 2015 and September 2016Slide9
Desired system
GeneralityConvert any personal app to a business versionAbility of enforcing arbitrary access control policiesMulti-entity management, Role-based access control (RBAC), granularity…PortabilityNo modifications (dependencies) on OSCompletenessStealthy channels: reflection, native code, dynamic load Cross-platformExtend to other platforms, e.g. iOS9Slide10
Challenges
Lack of OS supportAndroid storage mechanism supports either data sharing or data isolation aloneDiversity of data access behaviorNative code, Java reflection, Dynamic loadingPerformance penaltyPopular resource virtualization-based solutions have the scalability issue10Slide11
Contributions
A proxy-based data access mechanism to enforce arbitrary access policies without OS dependencyAn application rewriting mechanism inject MAM features by hooking system calls to achieve complete mediationA prototype system with low latency and resource consumption 11Slide12
Outline
IntroductionMotivationSystem OverviewEvaluationConclusion12Slide13
Security model
13Slide14
Application rewriting
Application decompilationNativeCustomized system calls, e.g., ioctl(), open()Override Global Offset Table (GOT) BytecodeService: wrap the app, overwrite the GOT before app startsActivity: message popup, e.g., policy violationManifest fileDeclaring the Service and Activity injectedRequest the permission to access mirror content providerRepack and sign14Slide15
Proxy-based data access mechanism
15Slide16
Shield the privileged data
File-systemopen(), creat(), rename(), mkdir(), remove(): rewrite the file path to the internal storage of AppShieldstat(), lstat(): pass the file descriptor to business file to fstat()Content providerMirror content providerSystem call ioctl(): redirect data request16Slide17
Security policies
File isolationMulti-entity management & RBACFine-grained file access controlContent provider isolation17Slide18
Outline
IntroductionMotivationSystem OverviewEvaluationConclusion18Slide19
Effectiveness
Select 50 popular apps from Google Play35 file related apps, 15 contact provider related apps1 app crashes; 2 apps file path “/./sdcard”1 app cannot be rewritten; use “Intent” to directly start system contact manager app 19File isolationMulti-entity management & RBAC
File-level granularityContent provider isolation
Succeed
33/35
31/35
31/35
14/15Slide20
Reliability
Select 1000 apps by popularity from Google Play in categories: Business, Finance, Medical, ProductivityExecute by ADB MonkeyOriginal version also crash: 29 in 35Crash without code modification: 6 in 3520TotalSucceedRewriting failureCrash1000
953 (95.3%)12 (1.2%)35 (3.5%)Slide21
Impact of application rewriting
Micro: overall latency in 1000 data access:Macro: overall time for human to open/close a window rendering the privileged data21File systemContent providerOriginalAppShieldOriginal
AppShieldMicro (s)
0.180
0.382
7.303
9.014
Macro (s)
1.472
1.524
1.068
1.194
Average memory usage increment:
28840.3KB
Average code size increment:
33.7KBSlide22
Comparision
AirWatchMOCANAGOODCitrixAndroid LAppShield *MethodSDK & App rewritingApp rewriting
SDKSDKOS modification
App rewriting
Isolation
Sandbox
Sandbox
Sandbox
Encryption
DAC
Sandbox
Multi-entity
management
No
No
No
No
No
Yes
RBAC
Yes
No
No
Yes
No
Yes
Granularity
Static
Static
Coarse dynamic
Static
Coarse dynamic
File-level dynamic
Sharing
Online
Online
Online
Local
Local
Local
Portability
High
High
High
High
Low
High
22Slide23
Conclusion
AppShield enforces arbitrary access control policies in the scenario of MAMApplication rewritingNo dependency on OS, high portabilitySystem call hooking, complete mediationLow overhead and impact on the original app 23Slide24
24
Thank you!http://list.cs.northwestern.edu/mobile/Questions?Slide25
System call h
ooking25