Android System Architecture

Android System Architecture

안드로이드는 리눅스 위에 자바를 얹은 것으로 묘사하는데 이 것으로 복합적인 구성을 가지고 있는 안드로이드를 정의하기에는 좀 잘못된 말이다. 안드로이드는 리눅스 커널 기반이며 이에 많은 추가와 수정을 가했다. 그 중 하나가 바로 안드로이드 자체 보안 기법이다. 

Android’s Sandbox

안드로이드가 리눅스 기반이라는 것은 유닉스 계열의 process isolation 그리고 최소한의 권한을 부여하는 원칙을 동반한다는 것을 의미한다. 예를들어 각각의 유저는 서로 시그널 또는 메모리에 접근하는 것이 불가능하다.  안드로이드는 UID GID 개념을 도입했지만 /etc/passwd 그리고 /etc/group 파일이 존재하지 않는다. 대신에 안드로이드는 AID 라고 하는 고유 식별자들을 위한 map 을 정의했다.

안드로이드 APP는 개발자들이 디바이스 기능을 개선하는 것을 허용한다. 그리고 안드로이드 프레임워크는 다양한 편의 기능에 접근하기 위한  풍부한 API 를 제공한다. 안드로이드 app 그리고 프레임워크 둘다. 자바로 프로그래밍 되어있으며 DalvikVM 안에서 실행된다. 가상머신은 효율적인 가상 레이어를 OS에 제공해준다. DalvikVM은 DEX(Dalvik Execuatble) byte code 포멧을 해석해주는 레지스터 기반 VM 이다.

유저 영역 native code 컴포넌트는 안드로이드 시스템 서비스들을 포함한다. (DBus, network service, Openssl, Webkit 등) 이들 중 몇몇 서비스들은 kernel-level 서비스와 통신한다. 반면에 다른 것들은 단순히 managed code를 위한 저수준의 native operation만 제공한다. 

파일 시스템 접곤과 별개로 추가적인 그룹들은 프로세스들에게 추가 권한을 추기 위해 사용된다. 예를 들어서 AID_INET 그룹의 경우 우저가 AF_INET 그리고 AF_INET6 소켓을 쓸 수 있는 권한을 부여한다. APP를 실행할 때 APP에 새로운 프로세스 실행을 위한 UID, GID 그리고 추가적인 그룹이 할당된다. 그리고 이렇게 고유한 UID 그리고 GID 에서 작동하는 것은 운영체제가 커널의 로우 레벨에 대한 제한을 할 수 있게 하며 이 것이 안드로이드 샌드박스의 핵심이다.

밑에 것은 HTC 폰에서 ps명령어를 실행한 것인데 각 APP 마다 서로 다른 UID를 가지고 있는 것을 확인할 수 있다. 

APP는 또한 APP 패키지에 있는 특별한 지시어를 통해 UID를 공유할 수 있다. 이 것은 나중에 더 알아보도록 하자. 프로세스를 위해 표시되는 유저 그리고 그룹 이름들은 실질적으로는 이러한 것들을 셋팅하고 가져오는 것은 POSIX 함수들로 이다.  예를 들어서 stubs.cpp 에 있는 getpwuid 함수가 있다. 안드로이드는 또한 APP를 위한 AID를 예약한다.  안드로이드 4.1 이 후에 멀티 유저 그리고 독립된 프로세스 유저를 위한 AID  추가.( 크롬 샌드박스를 위한) system/core/include/private/android_filesystem_config.h 를 보면 AID 정의를 볼 수가 있다. 

packages.xml 은 APP를 위한 UID 와 APP가 요구한 권한이 표시된다.

이 중에서 그룹 - 권한을 매핑해주는 파일은 /etc/permissions/platform.xml 에 저장되어 있다. 

Android Permission

API 에 대한 권한, 파일에 대한 권한, IPC에 대한권한 등이 존재하며 이들은 서로 엮여 있다. 높은 권한은 lower-level OS 기능으로 다시 매핑된다. 예를 들어 socket, 블루투스 장치, 파일 시스템 등이다. 유저의 권한 그리고 추가적인 그룹을 결정하기 위해서  AndroidManifest.xml 에 에 있는 권한이 인스톨될 때 packages.xml 로 들어갑니다. 그리고 이러한 엔트리들은 적합한 권한을 부여하기 위해 사용된다. 

API Permissions

API 권한은 높은 레벨에 대한 접근 가능을 포함한다. API의 공통권한은 READ_PHONE_STATE 이다. 따라서 핸드폰 정보에 대한 내용은 쿼리가 가능하다. 몇몇의 권한은 커널 레벨과 관련이 있다.

File System 

안드로이드 APP Sandbox 는 유닉스 파일 시스템 권한을 그대로 이어받는데 안드로이드 앱 고유의 UID 그리고 GID 는 기본적으로 해당 앱 각자의 파일 시스템에만 접근 가능하다. 

Looking Closer at the Layers

Android Applications

구글 같은 곳에서 핸드폰에 기본적으로 설치시켜주는 앱은 /system/app 에 존재하며 루트권한을 가질 수도 있기 때문에 상당히 흥미롭다. 그리고 구글플레이 또는 사용자가 설치한 앱은/data/app 디렉토리에 저장된다. 

주요 앱 컴포넌트 

AndroidManifest.xml

모든 안드로이드 어플리케이션은 AndroidManifest.xml 파일을 포함해야한다. 이러한 XML 파일은 APP에 대한 다양한 정보들을 가지고 있다. 

- 고유의 패키지명

- 액티비티, 서비스, 브로드캐스트 리시버, Instrumentation definitions 

- 퍼미션 정의 

- 패키지되는 외부라이브러리에 대한 정보는 앱에 의해 사용된다. 

manifest 에서 중요나 부분 중 하나는 sharedUserID 속성이다. 만약 두 개의 APP가 같은 키로 사이닝 했다면 이 것을 통해서 구분할 수 있다. 이 두 앱이 함께 실행될 경우 같은 UID 아래서 실행된다. 이 것은 앱이 같은 파일 시스템 그리고 다른 리소스에 접근하게 해준다, manifest 파일은 이클립스 안드로이드 스튜디오 같은 개발 환경에서 만들어진다. 그리고 xml 플레인 텍스트에서 바이너리 xml로 변환된다. 

intent

어플리케이션 내부의 커뮤니케이션에서 중요한 부분이 바로 intent 이다.  이러한 intent 는  실행할 명령들에 대한 정보를 가지고 있는 오브젝트이다. 

the optional target

component on which to act, and additional fl ags or other supporting information

(which may be signifi cant to the recipient). Nearly all common actions—such as

tapping a link in a mail message to launch the browser, notifying the messaging

app that an SMS has arrived, and installing and removing applications—involve

Intents being passed around the system.

This is akin to an IPC or remote procedure call (RPC) facility where applications’

components can interact programmatically with one another, invoking

functionality and sharing data. Given the enforcement of the sandbox at a lower

level (fi le system, AIDs, and so on), applications typically interact via this API.

The Android runtime acts as a reference monitor, enforcing permissions checks

for Intents, if the caller and/or the callee specify permission requirements for

sending or receipt of messages.

When declaring specifi c components in a manifest, it is possible to specify

an intent fi lter, which declares the criteria to which the endpoint handles. Intent

fi lters are especially used when dealing with intents that do not have a specifi c

destination, called implicit intents.

For example, suppose an application’s manifest contains a custom permission

com.wiley.permission.INSTALL_WIDGET, and an activity, com.wiley.MyApp

.InstallWidgetActivity, which uses this permission to restrict launching of

the InstallWidgetActivity:

<manifest android:versionCode="1" android:versionName="1.0"

package="com.wiley.MyApp"

...

<permission android:name="com.wiley.permission.INSTALL_WIDGET"

android:protectionLevel="signature" />

...

<activity android:name=".InstallWidgetActivity"

android:permission="com.wiley.permission.INSTALL_WIDGET"/>

Here we see the permission declaration and the activity declaration. Note,

too, that the permission has a protectionLevel attribute of signature. This

limits which other applications can request this permission to just those signed

by the same key as the app that initially defi ned this permission.

Services

서비스는 ui없이 동작하는 앱의 컴포넌트이다. 이 것들은 유저가 직접 뷰로서 볼 수는 없지만 intent를 주고 받기 위해 IPC 를 이용할 수 있다.