이 페이지에서는 새 플랫폼 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 등
|
결과적으로 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
아래에 나열하여 이전 공급업체 버전에는 일치하는 유형이 없음을 명시해야 합니다.
플랫폼 정책, 공급업체 정책, 매핑 파일의 조합을 통해 공급업체 정책을 업데이트하지 않고 시스템을 업데이트할 수 있습니다. 또한 버전이 지정된 속성으로의 변환이 자동으로 이루어지므로 공급업체 정책에서 버전 관리를 처리할 필요가 없으며 공개 유형을 그대로 사용하면 됩니다.
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
파티션에 설치하려면 기기 구현자나 공급업체는 다음을 실행해야 합니다.
- 생성된 기본 매핑 파일을 ver,
system_ext
,product
파티션에서 소스 트리로 복사합니다. - 필요에 따라 매핑 파일을 수정합니다.
-
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
이 되지 않아야 합니다.
- 공급업체 바이너리에 과한 이러한 플랫폼 종속 항목은 HIDL HAL 뒤에 있어야 합니다.
신뢰할 수 없는 속성
임의 코드를 호스팅하는 신뢰할 수 없는 앱은 HwBinder 서비스에 액세스해서는 안 됩니다. 단, 이러한 앱에서 액세스해도 충분히 안전한 것으로 간주되는 때는 예외입니다(아래의 안전 서비스 참조). 이와 관련한 두 가지 주요 이유는 다음과 같습니다.
- HIDL은 현재 호출자 UID 정보를 노출하지 않으므로 HwBinder 서버는 클라이언트 인증을 실행하지 않습니다. HIDL이 그러한 데이터를 노출했더라도 많은 HwBinder 서비스는 앱보다 낮은 수준(예: HAL)에서 작동하거나 승인에 앱 ID를 사용해서는 안 됩니다. 따라서 보안을 위해 모든 HwBinder 서비스는 모든 클라이언트가 서비스에서 제공하는 작업을 실행할 수 있는 권한을 똑같이 부여받았다고 간주하는 것이 기본 가정입니다.
- 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
에 의해 로드되어야 합니다.
- 기기별 라벨이 없는 Android 플랫폼
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
에 의해 로드되어야 합니다.
- 기기별 라벨이 없는 Android 플랫폼
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.
에 상주해야 합니다.
- 기기별 변경사항이 없는 Android 플랫폼
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/.
에 상주해야 합니다.
- 기기별 변경사항이 없는 Android 플랫폼
- 비 플랫폼
mac_permissions.xml
- 기기
Boardconfig.mk
파일의BOARD_SEPOLICY_DIRS
가 가리키는 디렉터리에 있는mac_permissions.xml
에서 빌드한 플랫폼mac_permissions.xml
의 기기별 확장입니다. vendor
파티션에 있는/vendor/etc/selinux/.
에 상주해야 합니다.
- 기기