정책 호환성

이 페이지에서는 새 플랫폼 SELinux 설정이 이전 공급업체 SELinux 설정과 다를 수 있는 플랫폼 무선 (OTA) 업데이트 관련 정책 호환성 문제를 Android가 어떻게 처리하는지 설명합니다.

객체 소유권 및 라벨 지정

플랫폼 및 공급업체 정책을 별도로 유지하려면 각 객체의 소유권을 명확하게 정의해야 합니다. 예를 들어 공급업체 정책에서 /dev/foo 라벨을 지정하고 플랫폼 정책에서 후속 OTA에서 /dev/foo 라벨을 지정하면 예기치 않은 거부와 같은 정의되지 않은 동작이 발생하거나 더 심각하게는 부팅 실패가 발생합니다. SELinux에서는 라벨 지정 충돌로 나타납니다. 기기 노드에는 마지막에 적용된 라벨로 확인되는 라벨이 하나만 있을 수 있습니다. 결과:

• 성공적으로 적용되지 않은 라벨에 액세스해야 하는 프로세스는 리소스에 대한 액세스 권한을 잃게 됩니다.
• 잘못된 기기 노드가 생성되었기 때문에 파일에 액세스할 수 있는 프로세스가 중단될 수 있습니다.

플랫폼 및 공급업체 라벨 간의 충돌은 속성, 서비스, 프로세스, 파일, 소켓 등 SELinux 라벨이 있는 모든 객체에서 발생할 수 있습니다. 이 문제를 방지하려면 이러한 객체의 소유권을 명확하게 정의해야 합니다.

유형/속성 네임스페이스 지정

라벨 충돌 외에도 SELinux 유형 및 속성 이름도 충돌할 수 있습니다. SELinux는 동일한 유형과 속성의 여러 선언을 허용하지 않습니다. 중복 선언이 있는 정책은 컴파일에 실패합니다. 유형 및 속성 이름 충돌을 방지하려면 모든 공급업체 선언이 vendor_ 접두사로 시작하는 것이 좋습니다. 예를 들어 공급업체는 type foo, domain; 대신 type vendor_foo, domain;를 사용해야 합니다.

파일 소유권

플랫폼 및 공급업체 정책은 둘 다 일반적으로 모든 파일 시스템에 라벨을 제공하기 때문에 파일 충돌을 방지하기가 어렵습니다. 유형 이름 지정과는 달리 파일의 네임스페이스 지정은 실용적이지 않습니다. 많은 파일이 커널에 의해 생성되기 때문입니다. 이러한 충돌을 방지하려면 본 섹션의 파일 시스템 이름 지정 지침을 따르세요. Android 8.0에서 이러한 지침은 기술적 시정 조치가 없는 권장사항입니다. 향후 이러한 권장사항은 공급업체 테스트 모음(VTS)에 의해 적용됩니다.

System(/system)

시스템 이미지만 file_contexts, service_contexts 등을 통해 /system 구성요소의 라벨을 제공해야 합니다. /system 구성요소의 라벨이 공급업체 정책에 추가되면 프레임워크 전용 OTA 업데이트가 불가능할 수 있습니다.

Vendor(/vendor)

AOSP SELinux 정책은 플랫폼이 상호작용하는 vendor 파티션의 일부에 이미 라벨을 지정함으로써 플랫폼 프로세스의 SELinux 규칙을 작성하여 vendor 파티션의 일부와 통신하거나 일부에 액세스할 수 있도록 합니다. 예:

/vendor 경로	플랫폼에서 제공하는 라벨	라벨에 따른 플랫폼 프로세스
/vendor(/.*)?	vendor_file	프레임워크의 모든 HAL 클라이언트, ueventd 등
/vendor/framework(/.*)?	vendor_framework_file	dex2oat, appdomain 등
/vendor/app(/.*)?	vendor_app_file	dex2oat, installd, idmap 등
/vendor/overlay(/.*)	vendor_overlay_file	system_server, zygote, idmap 등

* 더 많은 예는 system/sepolicy/private/file_contexts를 참조하세요.

결과적으로 vendor 파티션의 추가 파일에 라벨을 지정할 때 다음과 같이 특정 규칙을 따라야 합니다 (neverallows를 통해 적용).

• vendor_file 은 vendor 파티션에서 모든 파일의 기본 라벨이어야 합니다. 플랫폼 정책에서는 이 라벨이 패스스루 HAL 구현에 액세스하도록 요구합니다.
• 공급업체 정책을 통해 vendor 파티션에 추가된 새로운 모든 exec_types에는 vendor_file_type 속성이 있어야 합니다. 이는 neverallows를 통해 적용됩니다.
• 향후 플랫폼/프레임워크 업데이트와의 충돌을 방지하려면 vendor 파티션에서 exec_types 외의 다른 라벨을 파일에 지정하지 않아야 합니다.
• AOSP에서 식별한 동일한 프로세스 HAL의 모든 라이브러리 종속 항목에는 same_process_hal_file.로 라벨을 지정해야 합니다.

Procfs(/proc)

/proc의 파일에는 genfscon 라벨만 사용하여 라벨을 지정할 수 있습니다. Android 7.0에서는 플랫폼 및 공급업체 정책이 모두 genfscon을 사용하여 procfs의 파일에 라벨을 지정했습니다.

권장사항: 플랫폼 정책만 /proc에 라벨을 지정합니다. 공급업체 프로세스에서 현재 기본 라벨 (proc)로 라벨이 지정된 /proc의 파일에 액세스해야 한다면 공급업체 정책은 파일에 명시적으로 라벨을 지정해서는 안 되며 대신 일반 proc 유형을 사용하여 공급업체 도메인의 규칙을 추가해야 합니다. 이렇게 하면 플랫폼 업데이트가 procfs를 통해 노출된 향후 커널 인터페이스를 수용하고 필요에 따라 명시적으로 라벨을 지정할 수 있습니다.

Debugfs(/sys/kernel/debug)

file_contexts와 genfscon을 둘 다 사용하여 Debugfs에 라벨을 지정할 수 있습니다. Android 7.0부터 Android 10까지는 플랫폼과 공급업체가 모두 debugfs에 라벨을 지정합니다.

Android 11에서는 프로덕션 기기에서 debugfs에 액세스하거나 이를 마운트할 수 없습니다. 기기 제조업체는 debugfs를 삭제해야 합니다.

Tracefs(/sys/kernel/debug/tracing)

file_contexts와 genfscon을 둘 다 사용하여 Tracefs에 라벨을 지정할 수 있습니다. Android 7.0에서는 플랫폼만 tracefs에 라벨을 지정합니다.

권장사항: 플랫폼만 tracefs에 라벨을 지정할 수 있습니다.

Sysfs(/sys)

file_contexts와 genfscon을 둘 다 사용하여 /sys의 파일에 라벨을 지정할 수 있습니다. Android 7.0에서는 플랫폼과 공급업체가 모두 genfscon을 사용하여 sysfs의 파일에 라벨을 지정합니다.

권장사항: 플랫폼은 기기에 고유하지 않은 sysfs 노드에 라벨을 지정할 수 있습니다. 노드가 기기에 고유하다면 공급업체만 파일에 라벨을 지정할 수 있습니다.

tmpfs(/dev)

file_contexts를 사용하여 /dev의 파일에 라벨을 지정할 수 있습니다. Android 7.0에서는 플랫폼과 공급업체가 모두 이 경로의 파일에 라벨을 지정합니다.

권장사항: 공급업체는 /dev/vendor (예: /dev/vendor/foo, /dev/vendor/socket/bar)의 파일에만 라벨을 지정할 수 있습니다.

Rootfs(/)

file_contexts를 사용하여 /의 파일에 라벨을 지정할 수 있습니다. Android 7.0에서는 플랫폼 및 공급업체가 모두 이 경로의 파일에 라벨을 지정합니다.

권장사항: 시스템만 /의 파일에 라벨을 지정할 수 있습니다.

Data(/data)

file_contexts와 seapp_contexts의 조합을 통해 데이터에 라벨을 지정할 수 있습니다.

권장사항: /data/vendor 외부에서의 공급업체 라벨 지정을 허용하지 않습니다. 플랫폼만 /data의 다른 부분에 라벨을 지정할 수 있습니다.

Genfs 라벨 버전

공급업체 API 수준 202504부터 system/sepolicy/compat/plat_sepolicy_genfs_ver.cil에서 genfscon로 할당된 최신 SELinux 라벨은 이전 vendor 파티션에 선택사항입니다. 이를 통해 이전 vendor 파티션이 기존 SEPolicy 구현을 유지할 수 있습니다. 이는 /vendor/etc/selinux/genfs_labels_version.txt에 저장된 Makefile 변수 BOARD_GENFS_LABELS_VERSION에 의해 제어됩니다.

예:

• 공급업체 API 수준 202404에서는 /sys/class/udc 노드에 기본적으로 sysfs 라벨이 지정됩니다.
• 공급업체 API 수준 202504부터 /sys/class/udc에 sysfs_udc 라벨이 지정됩니다.

하지만 API 수준 202404를 사용하는 vendor 파티션이 기본 sysfs 라벨이나 공급업체별 라벨을 사용하여 /sys/class/udc를 사용할 수 있습니다. /sys/class/udc에 무조건 sysfs_udc 라벨을 지정하면 이러한 vendor 파티션과의 호환성이 깨질 수 있습니다. BOARD_GENFS_LABELS_VERSION를 확인하면 플랫폼은 이전 vendor 파티션에 이전 라벨과 권한을 계속 사용합니다.

BOARD_GENFS_LABELS_VERSION은 공급업체 API 수준 이상일 수 있습니다. 예를 들어 API 수준 202404를 사용하는 vendor 파티션은 202504에 도입된 새 라벨을 채택하기 위해 BOARD_GENFS_LABELS_VERSION을 202504로 설정할 수 있습니다. 202504 관련 genfs 라벨 목록을 참고하세요.

genfscon 노드에 라벨을 지정할 때 플랫폼은 이전 vendor 파티션을 고려하고 필요한 경우 호환성을 위해 대체 메커니즘을 구현해야 합니다. 플랫폼은 플랫폼 전용 라이브러리를 사용하여 genfs 라벨 버전을 쿼리할 수 있습니다.

• 네이티브에서는 libgenfslabelsversion를 사용합니다. libgenfslabelsversion의 헤더 파일은 genfslabelsversion.h을 참고하세요.
• Java에서는 android.os.SELinux.getGenfsLabelsVersion()을 사용합니다.

플랫폼-공개 정책

플랫폼 SELinux 정책은 비공개와 공개로 나뉩니다. 플랫폼 공개 정책은 항상 공급업체 API 수준에서 사용할 수 있는 유형과 속성으로 구성되며 플랫폼과 공급업체 간의 API 역할을 합니다. 이 정책은 공급업체 정책 작성자에게 공개되므로 공급업체가 공급업체 정책 파일을 빌드할 수 있습니다. 파일이 플랫폼 비공개 정책과 결합되면 기기와 관련하여 완전한 기능을 갖춘 정책이 생성됩니다. 플랫폼 공개 정책은 system/sepolicy/public에 정의되어 있습니다.

예를 들어 공급업체 컨텍스트에서 init 프로세스를 나타내는 vendor_init 유형은 system/sepolicy/public/vendor_init.te 아래에 정의됩니다.

type vendor_init, domain;

공급업체는 vendor_init 유형을 참고하여 맞춤 정책 규칙을 작성할 수 있습니다.

# Allow vendor_init to set vendor_audio_prop in vendor's init scripts
set_prop(vendor_init, vendor_audio_prop)

호환성 속성

SELinux 정책은 특정 객체 클래스 및 권한의 소스 유형과 타겟 유형 간의 상호작용입니다. SELinux 정책의 영향을 받는 모든 객체 (예: 프로세스, 파일)에는 하나의 유형만 있을 수 있지만 유형에는 여러 속성이 있을 수 있습니다.

정책은 주로 기존 유형 측면에서 작성됩니다. 여기서 vendor_init과 debugfs은 모두 유형입니다.

allow vendor_init debugfs:dir { mounton };

즉, 정책이 모든 유형을 숙지한 상태에서 작성되었기 때문에 효과가 있습니다. 그러나 공급업체 정책 및 플랫폼 정책이 특정 유형을 사용하고 특정 객체의 라벨이 이러한 정책 중 하나에서만 변경된다면 다른 정책에는 이전에 사용했던 액세스 권한을 얻거나 잃은 정책이 포함될 수 있습니다. 예를 들어 플랫폼 정책에서 sysfs 노드에 sysfs 라벨을 지정한다고 가정해 보겠습니다.

/sys(/.*)? u:object_r:sysfs:s0

공급업체 정책은 sysfs 라벨이 지정된 /sys/usb에 대한 액세스 권한을 부여합니다.

allow vendor_init sysfs:chr_file rw_file_perms;

플랫폼 정책이 /sys/usb에 sysfs_usb 라벨을 지정하도록 변경되면 공급업체 정책은 동일하게 유지되지만 새로운 sysfs_usb 유형의 정책이 없기 때문에 vendor_init은 /sys/usb에 대한 액세스 권한을 잃게 됩니다.

/sys/usb u:object_r:sysfs_usb:s0

이 문제를 해결하기 위해 Android에서는 버전이 지정된 속성이라는 개념을 도입합니다. 컴파일 시간에 빌드 시스템은 공급업체 정책에 사용된 플랫폼 공개 유형을 이러한 버전이 지정된 속성으로 자동 변환합니다. 이 변환은 버전이 지정된 속성을 플랫폼의 하나 이상의 공개 유형과 연결하는 매핑 파일에 의해 사용 설정됩니다.

예를 들어 /sys/usb에 202504 플랫폼 정책에서 sysfs 라벨이 지정되고 202504 공급업체 정책에서 /sys/usb에 대한 vendor_init 액세스 권한을 부여한다고 가정해 보겠습니다. 이 경우에는 다음과 같습니다.

• 공급업체 정책은 202504 플랫폼 정책에서 /sys/usb이 sysfs로 라벨이 지정되어 있으므로 allow vendor_init sysfs:chr_file rw_file_perms; 규칙을 작성합니다. 빌드 시스템이 공급업체 정책을 컴파일하면 규칙이 allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms;로 자동 변환됩니다. vendor_init_202504 및 sysfs_202504 속성은 플랫폼에서 정의한 유형인 vendor_init 및 sysfs 유형에 해당합니다.
• 빌드 시스템은 ID 매핑 파일 /system/etc/selinux/mapping/202504.cil를 생성합니다. system 및 vendor 파티션이 모두 동일한 202504 버전을 사용하므로 매핑 파일에는 type_202504에서 type로의 ID 매핑이 포함됩니다. 예를 들어 vendor_init_202504는 vendor_init에 매핑되고 sysfs_202504은 sysfs에 매핑됩니다.

  (typeattributeset sysfs_202504 (sysfs))
  (typeattributeset vendor_init_202504 (vendor_init))
  ...

버전이 202504에서 202604로 변경되면 202504 vendor 파티션의 새 매핑 파일이 system/sepolicy/private/compat/202504/202504.cil 아래에 생성되며 이는 202604 이상 system 파티션의 /system/etc/selinux/mapping/202504.cil에 설치됩니다. 처음에 이 매핑 파일에는 앞에서 설명한 대로 ID 매핑이 포함됩니다. /sys/usb의 새 라벨 sysfs_usb이 202604 플랫폼 정책에 추가되면 매핑 파일이 업데이트되어 sysfs_202504을 sysfs_usb에 매핑합니다.

(typeattributeset sysfs_202504 (sysfs sysfs_usb))
(typeattributeset vendor_init_202504 (vendor_init))
...

이 업데이트를 통해 변환된 공급업체 정책 규칙 allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms;이 새로운 sysfs_usb 유형에 vendor_init 액세스 권한을 자동으로 부여할 수 있습니다.

이전 vendor 파티션과의 호환성을 유지하려면 새 공개 유형이 추가될 때마다 해당 유형을 매핑 파일 system/sepolicy/private/compat/ver/ver.cil의 버전이 지정된 속성 중 하나에 매핑하거나 system/sepolicy/private/compat/ver/ver.ignore.cil 아래에 나열하여 이전 공급업체 버전에는 일치하는 유형이 없음을 명시해야 합니다.

플랫폼 정책, 공급업체 정책, 매핑 파일의 조합을 통해 공급업체 정책을 업데이트하지 않고 시스템을 업데이트할 수 있습니다. 또한 버전이 지정된 속성으로의 변환이 자동으로 이루어지므로 공급업체 정책에서 버전 관리를 처리할 필요가 없으며 공개 유형을 그대로 사용하면 됩니다.

참고: 공개 속성은 앞에서 언급한 공개 유형과 달리 버전이 지정되지 않습니다. 속성은 구체적인 유형이 아니며 속성에 부여된 권한은 속성에 매핑되는 모든 유형에 자동으로 적용됩니다. 예를 들어 공급업체 정책에서 appdomain 권한을 부여하면 정책이 작성될 때 존재하지 않았던 최신 시스템 앱을 비롯한 모든 앱에 권한이 자동으로 적용됩니다.

system_ext 공개 및 제품 공개 정책

Android 11부터 system_ext 및 product 파티션이 지정된 공개 유형을 vendor 파티션으로 내보낼 수 있습니다. 플랫폼 공개 정책과 마찬가지로 공급업체 정책은 버전이 지정된 속성으로 자동 변환되는 유형과 규칙을 사용합니다. 예를 들어 type에서 type_ver으로 변환되는데 여기서 ver은 vendor 파티션의 공급업체 API 수준입니다.

system_ext 및 product 파티션이 동일한 플랫폼 버전 ver을 기반으로 하는 경우 빌드 시스템은 type에서 type_ver로의 ID 매핑이 포함된 system_ext/etc/selinux/mapping/ver.cil 및 product/etc/selinux/mapping/ver.cil의 기본 매핑 파일을 생성합니다. 공급업체 정책은 버전이 지정된 속성 type_ver으로 type에 액세스할 수 있습니다.

vendor 파티션이 ver에 유지되는 동안 system_ext 및 product 파티션만 업데이트되는 경우 (예: ver에서 ver+1 이상으로) 공급업체 정책은 system_ext 및 product 파티션 유형에 대한 액세스 권한을 잃을 수 있습니다. 손상을 방지하려면 system_ext 및 product 파티션은 구체적인 유형의 매핑 파일을 type_ver 속성으로 제공해야 합니다. 각 파트너는 ver+1 (또는 이후) system_ext 및 product 파티션으로 ver vendor 파티션을 지원하는 경우 매핑 파일을 유지관리해야 합니다.

매핑 파일을 system_ext 및 product 파티션에 설치하려면 기기 구현자나 공급업체는 다음을 실행해야 합니다.

1. 생성된 기본 매핑 파일을 ver, system_ext, product 파티션에서 소스 트리로 복사합니다.
2. 필요에 따라 매핑 파일을 수정합니다.
3. ver+1 (또는 그 이상) system_ext 및 product 파티션에 매핑 파일을 설치합니다.

예를 들어 202504 system_ext 파티션에 foo_type이라는 공개 유형이 하나 있다고 가정해 보겠습니다. 그러면 202504 system_ext 파티션의 system_ext/etc/selinux/mapping/202504.cil은 다음과 같습니다.

(typeattributeset foo_type_202504 (foo_type))
(expandtypeattribute foo_type_202504 true)
(typeattribute foo_type_202504)

bar_type이 202604 system_ext에 추가되고 bar_type이 202504 vendor 파티션의 foo_type에 매핑되어야 하는 경우 202504.cil을 (typeattributeset foo_type_202504 (foo_type))에서 (typeattributeset foo_type_202504 (foo_type bar_type))로 업데이트한 후 202604 system_ext 파티션에 설치할 수 있습니다. 202504 vendor 파티션은 202604 system_ext의 foo_type 및 bar_type에 계속 액세스할 수 있습니다.

Android 9의 속성 변경사항

Android 9로 업그레이드하는 기기는 다음 속성을 사용할 수 있지만 Android 9로 실행되는 기기는 다음 속성을 사용하지 않아야 합니다.

위반자 속성

Android 9에는 다음과 같은 도메인 관련 속성이 포함되어 있습니다.

• data_between_core_and_vendor_violators. vendor와 coredomains 간 경로를 통해 파일을 공유하지 않아야 하는 요구사항을 위반하는 모든 도메인의 속성입니다. 플랫폼 및 공급업체 프로세스는 온디스크 파일을 사용하여 통신해서는 안 됩니다(불안정한 ABI). 권장사항
  • 공급업체 코드는 /data/vendor를 사용해야 합니다.
  • 시스템은 /data/vendor를 사용하지 않아야 합니다.
• system_executes_vendor_violators. 공급업체 바이너리를 실행하지 않아야 하는 요구사항을 위반하는 모든 시스템 도메인 (init 및 shell domains 제외)의 속성입니다. 공급업체 바이너리를 실행하면 API가 불안정해집니다. 플랫폼은 공급업체 바이너리를 직접 실행해서는 안 됩니다. 권장사항
  • 공급업체 바이너리에 과한 이러한 플랫폼 종속 항목은 HIDL HAL 뒤에 있어야 합니다.

    또는

  • 공급업체 바이너리에 액세스해야 하는 coredomains는 vendor 파티션으로 이동되어야 합니다. 따라서 coredomain이 되지 않아야 합니다.

신뢰할 수 없는 속성

임의 코드를 호스팅하는 신뢰할 수 없는 앱은 HwBinder 서비스에 액세스해서는 안 됩니다. 단, 이러한 앱에서 액세스해도 충분히 안전한 것으로 간주되는 때는 예외입니다(아래의 안전 서비스 참조). 이와 관련한 두 가지 주요 이유는 다음과 같습니다.

1. HIDL은 현재 호출자 UID 정보를 노출하지 않으므로 HwBinder 서버는 클라이언트 인증을 실행하지 않습니다. HIDL이 그러한 데이터를 노출했더라도 많은 HwBinder 서비스는 앱보다 낮은 수준(예: HAL)에서 작동하거나 승인에 앱 ID를 사용해서는 안 됩니다. 따라서 보안을 위해 모든 HwBinder 서비스는 모든 클라이언트가 서비스에서 제공하는 작업을 실행할 수 있는 권한을 똑같이 부여받았다고 간주하는 것이 기본 가정입니다.
2. HAL 서버(HwBinder 서비스의 하위 집합)는 system/core 구성요소보다 보안 문제 발생률이 더 높은 코드를 포함하고 있으며 스택의 하위 레이어(하드웨어에 이르기까지)에 액세스할 수 있으므로 Android 보안 모델을 우회할 기회가 증가합니다.

안전 서비스

안전 서비스에는 다음이 포함됩니다.

• same_process_hwservice. 이러한 서비스는 정의에 따라 클라이언트 프로세스에서 실행되므로 프로세스가 실행되는 클라이언트 도메인과 동일한 액세스 권한을 갖습니다.
• coredomain_hwservice. 이러한 서비스는 이유 2와 관련된 위험을 초래하지 않습니다.
• hal_configstore_ISurfaceFlingerConfigs. 이 서비스는 어떤 도메인에서도 사용할 수 있도록 특별히 설계되었습니다.
• hal_graphics_allocator_hwservice. 이러한 작업은 surfaceflinger 바인더 서비스에 의해서도 제공되며, 앱은 액세스가 허용됩니다.
• hal_omx_hwservice. 이 서비스는 mediacodec 바인더 서비스의 HwBinder 버전으로, 앱은 액세스가 허용됩니다.
• hal_codec2_hwservice. 이 서비스는 hal_omx_hwservice의 최신 버전입니다.

유용한 속성

안전하지 않은 것으로 간주되는 모든 hwservices에는 untrusted_app_visible_hwservice 속성이 있습니다. 상응하는 HAL 서버에는 untrusted_app_visible_halserver 속성이 있습니다. Android 9로 실행되는 기기는 untrusted 속성을 사용해서는 안 됩니다.

권장사항:

• 신뢰할 수 없는 앱은 대신 공급업체 HIDL HAL과 통신하는 시스템 서비스와 통신해야 합니다. 예를 들어 앱이 binderservicedomain과 통신할 수 있으며 결과적으로 mediaserver(이는 binderservicedomain임)가 hal_graphics_allocator와 통신합니다.

  또는

• vendor HAL에 직접 액세스해야 하는 앱은 자체적인 공급업체 정의 SEPolicy 도메인을 보유해야 합니다.

파일 속성 테스트

Android 9에는 특정 위치의 모든 파일에 적절한 속성이 있는지 확인하는 빌드 시간 테스트가 포함되어 있습니다(예: sysfs의 모든 파일에는 필수 sysfs_type 속성이 있음).

SELinux 컨텍스트 라벨 지정

플랫폼 sepolicy와 공급업체 sepolicy 사이의 구별을 지원하기 위해 시스템은 SELinux 컨텍스트 파일을 다르게 빌드하여 별도로 분리합니다.

파일 컨텍스트

Android 8.0에서는 다음과 같은 file_contexts 관련 변경사항을 도입했습니다.

• 부팅 시 기기의 추가 컴파일 오버헤드를 방지하기 위해 file_contexts는 이제 바이너리 형식으로 존재하지 않습니다. 대신 {property, service}_contexts와 같은 읽기 쉬운 정규 표현식 텍스트 파일로 존재합니다(7.0 이전과 같음).
• file_contexts는 다음과 같은 두 파일로 나뉩니다.
  • plat_file_contexts
    • 기기별 라벨이 없는 Android 플랫폼 file_context입니다. 단, sepolicy 파일이 제대로 작동할 수 있도록 정확하게 라벨이 지정되어야 하는 /vendor 파티션의 일부에는 라벨을 지정합니다.
    • 기기의 system 파티션에 있는 /system/etc/selinux/plat_file_contexts에 상주해야 하며 시작 시 공급업체 file_context와 함께 init에 의해 로드되어야 합니다.
  • vendor_file_contexts
    • 기기 Boardconfig.mk 파일의 BOARD_SEPOLICY_DIRS가 가리키는 디렉터리에 있는 file_contexts를 결합하여 빌드한 기기별 file_context입니다.
    • vendor 파티션의 /vendor/etc/selinux/vendor_file_contexts에 설치되어야 하며 시작 시 플랫폼 file_context와 함께 init에 의해 로드되어야 합니다.

속성 컨텍스트

Android 8.0에서 property_contexts는 다음과 같은 두 파일로 나뉩니다.

• plat_property_contexts
  • 기기별 라벨이 없는 Android 플랫폼 property_context입니다.
  • system 파티션에 있는 /system/etc/selinux/plat_property_contexts에 상주해야 하며 시작 시 공급업체 property_contexts와 함께 init에 의해 로드되어야 합니다.
• vendor_property_contexts
  • 기기 Boardconfig.mk 파일의 BOARD_SEPOLICY_DIRS가 가리키는 디렉터리에 있는 property_contexts를 결합하여 빌드한 기기별 property_context입니다.
  • vendor 파티션에 있는 /vendor/etc/selinux/vendor_property_contexts에 상주해야 하며 시작 시 플랫폼 property_context와 함께 init에 의해 로드되어야 합니다.

서비스 컨텍스트

Android 8.0에서 service_contexts는 다음과 같은 파일로 나뉩니다.

• plat_service_contexts
  • servicemanager를 위한 Android 플랫폼별 service_context이며 service_context에는 기기별 라벨이 없습니다.
  • system 파티션에 있는 /system/etc/selinux/plat_service_contexts에 상주해야 하며 시작 시 공급업체 service_contexts와 함께 servicemanager에 의해 로드되어야 합니다.
• vendor_service_contexts
  • 기기 Boardconfig.mk 파일의 BOARD_SEPOLICY_DIRS가 가리키는 디렉터리에 있는 service_contexts를 결합하여 빌드한 기기별 service_context입니다.
  • vendor 파티션에 있는 /vendor/etc/selinux/vendor_service_contexts에 상주해야 하며 시작 시 플랫폼 service_contexts와 함께 servicemanager에 의해 로드되어야 합니다.
  • servicemanager는 부팅 시 이 파일을 찾지만 완벽하게 준수하는 TREBLE 기기에서는 vendor_service_contexts가 존재하지 않아야 합니다. vendor 프로세스와 system 프로세스 간의 모든 상호작용이 반드시 hwservicemanager/hwbinder를 거쳐야 하기 때문입니다.
• plat_hwservice_contexts
  • hwservicemanager를 위한 Android 플랫폼 hwservice_context로, 기기별 라벨이 없습니다.
  • system 파티션에 있는 /system/etc/selinux/plat_hwservice_contexts에 상주해야 하며 시작 시 vendor_hwservice_contexts와 함께 hwservicemanager에 의해 로드되어야 합니다.
• vendor_hwservice_contexts
  • 기기 Boardconfig.mk 파일의 BOARD_SEPOLICY_DIRS가 가리키는 디렉터리에 있는 hwservice_contexts를 결합하여 빌드한 기기별 hwservice_context입니다.
  • vendor 파티션에 있는 /vendor/etc/selinux/vendor_hwservice_contexts에 상주해야 하며 시작 시 plat_service_contexts와 함께 hwservicemanager에 의해 로드되어야 합니다.
• vndservice_contexts
  • 기기 Boardconfig.mk 파일의 BOARD_SEPOLICY_DIRS가 가리키는 디렉터리에 있는 vndservice_contexts를 결합하여 빌드한 vndservicemanager를 위한 기기별 service_context입니다.
  • 이 파일은 vendor 파티션에 있는 /vendor/etc/selinux/vndservice_contexts에 상주해야 하며 시작 시 vndservicemanager에 의해 로드되어야 합니다.

Seapp 컨텍스트

Android 8.0에서 seapp_contexts는 다음과 같은 두 파일로 나뉩니다.

• plat_seapp_contexts
  • 기기별 변경사항이 없는 Android 플랫폼 seapp_context입니다.
  • system 파티션에 있는 /system/etc/selinux/plat_seapp_contexts.에 상주해야 합니다.
• vendor_seapp_contexts
  • 기기 Boardconfig.mk 파일의 BOARD_SEPOLICY_DIRS가 가리키는 디렉터리에 있는 seapp_contexts를 결합하여 빌드한 플랫폼 seapp_context의 기기별 확장입니다.
  • vendor 파티션에 있는 /vendor/etc/selinux/vendor_seapp_contexts에 상주해야 합니다.

MAC 권한

Android 8.0에서 mac_permissions.xml는 다음과 같은 두 파일로 나뉩니다.

• 플랫폼mac_permissions.xml
  • 기기별 변경사항이 없는 Android 플랫폼 mac_permissions.xml입니다.
  • system 파티션에 있는 /system/etc/selinux/.에 상주해야 합니다.
• 비 플랫폼 mac_permissions.xml
  • 기기 Boardconfig.mk 파일의 BOARD_SEPOLICY_DIRS가 가리키는 디렉터리에 있는 mac_permissions.xml에서 빌드한 플랫폼 mac_permissions.xml의 기기별 확장입니다.
  • vendor 파티션에 있는 /vendor/etc/selinux/.에 상주해야 합니다.