Tùy chỉnh SELinux

Sau khi bạn đã tích hợp chức năng SELinux ở cấp độ cơ bản và phân tích kỹ lưỡng kết quả, bạn có thể thêm cài đặt chính sách của riêng mình để thực hiện các tùy chỉnh của mình cho hệ điều hành Android. Các chính sách này vẫn phải đáp ứng các yêu cầu của chương trình Tương thích với Android và không được xóa cài đặt SELinux mặc định.

Các nhà sản xuất không nên loại bỏ chính sách SELinux hiện có. Nếu không, họ có nguy cơ phá vỡ quá trình triển khai Android SELinux và các ứng dụng mà nó quản lý. Điều này bao gồm các ứng dụng của bên thứ ba có thể sẽ cần được cải thiện để tuân thủ và hoạt động. Các ứng dụng không được yêu cầu sửa đổi để tiếp tục hoạt động trên các thiết bị hỗ trợ SELinux.

Khi bắt tay vào tùy chỉnh SELinux, hãy nhớ:

  • Viết chính sách SELinux cho tất cả các daemon mới
  • Sử dụng các miền được xác định trước bất cứ khi nào thích hợp
  • Chỉ định miền cho bất kỳ quy trình nào được sinh ra dưới dạng dịch vụ init
  • Làm quen với macro trước khi viết chính sách
  • Gửi các thay đổi về chính sách cốt lõi tới AOSP

Và hãy nhớ đừng:

  • Tạo chính sách không tương thích
  • Cho phép tùy chỉnh chính sách người dùng cuối
  • Cho phép tùy chỉnh chính sách MDM
  • Sợ người dùng vi phạm chính sách
  • Thêm cửa hậu

Xem phần Tính năng bảo mật hạt nhân của tài liệu Định nghĩa tương thích Android để biết các yêu cầu cụ thể.

SELinux sử dụng cách tiếp cận danh sách trắng, nghĩa là tất cả quyền truy cập phải được cho phép rõ ràng trong chính sách để được cấp. Vì chính sách SELinux mặc định của Android đã hỗ trợ Dự án mã nguồn mở Android nên bạn không cần phải sửa đổi cài đặt SELinux theo bất kỳ cách nào. Nếu bạn tùy chỉnh cài đặt SELinux, hãy hết sức cẩn thận để không làm hỏng các ứng dụng hiện có. Để bắt đầu:

  1. Sử dụng hạt nhân Android mới nhất .
  2. Áp dụng nguyên tắc đặc quyền tối thiểu .
  3. Chỉ giải quyết các bổ sung của riêng bạn cho Android. Chính sách mặc định hoạt động tự động với cơ sở mã Dự án mã nguồn mở Android .
  4. Phân chia các thành phần phần mềm thành các mô-đun thực hiện các nhiệm vụ đơn lẻ.
  5. Tạo các chính sách SELinux để tách biệt các tác vụ đó khỏi các chức năng không liên quan.
  6. Đặt các chính sách đó trong các tệp *.te (phần mở rộng cho các tệp nguồn chính sách SELinux) trong thư mục /device/ manufacturer / device-name /sepolicy và sử dụng các biến BOARD_SEPOLICY để đưa chúng vào bản dựng của bạn.
  7. Ban đầu hãy cho phép các tên miền mới. Điều này được thực hiện bằng cách sử dụng một khai báo cho phép trong tệp .te của miền.
  8. Phân tích kết quả và tinh chỉnh định nghĩa tên miền của bạn.
  9. Xóa tuyên bố cho phép khi không có từ chối nào nữa xuất hiện trong bản dựng userdebug.

Sau khi bạn đã tích hợp thay đổi chính sách SELinux của mình, hãy thêm một bước vào quy trình phát triển của bạn để đảm bảo khả năng tương thích SELinux trong tương lai. Trong một quy trình phát triển phần mềm lý tưởng, chính sách SELinux chỉ thay đổi khi mô hình phần mềm thay đổi chứ không phải khi triển khai thực tế.

Khi bạn bắt đầu tùy chỉnh SELinux, trước tiên hãy kiểm tra các bổ sung của bạn cho Android. Nếu bạn đã thêm một thành phần thực hiện chức năng mới, hãy đảm bảo thành phần đó đáp ứng chính sách bảo mật của Android cũng như mọi chính sách liên quan do OEM tạo ra trước khi bật chế độ thực thi.

Để ngăn chặn những sự cố không đáng có, tốt hơn là nên sử dụng phạm vi rộng và quá tương thích hơn là quá hạn chế và không tương thích, dẫn đến chức năng của thiết bị bị hỏng. Ngược lại, nếu những thay đổi của bạn sẽ mang lại lợi ích cho người khác, bạn nên gửi các sửa đổi đối với chính sách SELinux mặc định dưới dạng bản vá . Nếu bản vá được áp dụng cho chính sách bảo mật mặc định, bạn sẽ không cần thực hiện thay đổi này với mỗi bản phát hành Android mới.

Tuyên bố chính sách mẫu

SELinux dựa trên ngôn ngữ máy tính M4 và do đó hỗ trợ nhiều loại macro để tiết kiệm thời gian.

Trong ví dụ sau, tất cả các miền đều được cấp quyền truy cập để đọc hoặc ghi vào /dev/null và đọc từ /dev/zero .

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

Câu lệnh tương tự này có thể được viết bằng macro SELinux *_file_perms (tốc ký):

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

Chính sách mẫu

Đây là một chính sách mẫu hoàn chỉnh cho DHCP mà chúng tôi sẽ xem xét bên dưới:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

Hãy mổ xẻ ví dụ:

Trong dòng đầu tiên, khai báo kiểu, trình nền DHCP kế thừa từ chính sách bảo mật cơ sở ( domain ). Từ các ví dụ câu lệnh trước, DHCP có thể đọc và ghi vào /dev/null .

Ở dòng thứ hai, DHCP được xác định là miền cho phép.

Trong dòng init_daemon_domain(dhcp) , chính sách nêu rõ DHCP được sinh ra từ init và được phép liên lạc với nó.

Trong dòng net_domain(dhcp) , chính sách này cho phép DHCP sử dụng chức năng mạng phổ biến từ miền net như đọc và ghi các gói TCP, giao tiếp qua ổ cắm và thực hiện các yêu cầu DNS.

Ở dòng allow dhcp proc_net:file write; , chính sách nêu rõ DHCP có thể ghi vào các tệp cụ thể trong /proc . Dòng này thể hiện việc ghi nhãn tập tin chi tiết của SELinux. Nó sử dụng nhãn proc_net để giới hạn quyền truy cập ghi vào các tệp trong /proc/sys/net .

Khối cuối cùng của ví dụ bắt đầu bằng allow dhcp netd:fd use; mô tả cách các ứng dụng có thể được phép tương tác với nhau. Chính sách này cho biết DHCP và netd có thể giao tiếp với nhau thông qua bộ mô tả tệp, tệp FIFO, ổ cắm datagram và ổ cắm luồng UNIX. DHCP chỉ có thể đọc và ghi từ các ổ cắm datagram và ổ cắm luồng UNIX chứ không thể tạo hoặc mở chúng.

Điều khiển có sẵn

Lớp học Sự cho phép
tài liệu
ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton
danh mục
add_name remove_name reparent search rmdir open audit_access execmod
ổ cắm
ioctl read write create getattr setattr lock relabelfrom relabelto append bind
connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
name_bind
hệ thống tập tin
mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget
quá trình
fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
execstack execheap setkeycreate setsockcreate
bảo vệ
compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy
khả năng
chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap

HƠN

VÀ HƠN THẾ NỮA

quy tắc không bao giờ cho phép

Các quy tắc neverallow của SELinux nghiêm cấm hành vi không bao giờ nên xảy ra. Với thử nghiệm khả năng tương thích , các quy tắc neverallow của SELinux hiện được thực thi trên các thiết bị.

Những hướng dẫn sau đây nhằm giúp nhà sản xuất tránh được các lỗi liên quan đến quy tắc neverallow trong quá trình tùy chỉnh. Các số quy tắc được sử dụng ở đây tương ứng với Android 5.1 và có thể thay đổi theo bản phát hành.

Quy tắc 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Xem trang man để biết ptrace . Khả năng sys_ptrace cấp khả năng ptrace bất kỳ quy trình nào, cho phép kiểm soát rất nhiều các quy trình khác và chỉ thuộc về các thành phần hệ thống được chỉ định, được nêu trong quy tắc. Nhu cầu về khả năng này thường cho thấy sự hiện diện của thứ gì đó không dành cho các bản dựng hướng tới người dùng hoặc chức năng không cần thiết. Loại bỏ thành phần không cần thiết.

Quy tắc 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
Quy tắc này nhằm ngăn chặn việc thực thi mã tùy ý trên hệ thống. Cụ thể, nó xác nhận rằng chỉ mã trên /system mới được thực thi, điều này cho phép đảm bảo an ninh nhờ các cơ chế như khởi động được xác minh. Thông thường, giải pháp tốt nhất khi gặp vấn đề với quy tắc neverallow này là di chuyển mã vi phạm sang phân vùng /system .

Tùy chỉnh SEpolicy trong Android 8.0+

Phần này cung cấp các hướng dẫn về chính sách SELinux của nhà cung cấp trong Android 8.0 trở lên, bao gồm thông tin chi tiết về các tiện ích mở rộng SEPolicy và SEPolicy của Dự án mã nguồn mở Android (AOSP). Để biết thêm thông tin về cách chính sách SELinux được giữ tương thích trên các phân vùng và phiên bản Android, hãy xem Khả năng tương thích .

Vị trí chính sách

Trong Android 7.0 trở về trước, nhà sản xuất thiết bị có thể thêm chính sách vào BOARD_SEPOLICY_DIRS , bao gồm cả chính sách nhằm tăng cường chính sách AOSP trên các loại thiết bị khác nhau. Trong Android 8.0 trở lên, việc thêm chính sách vào BOARD_SEPOLICY_DIRS sẽ chỉ đặt chính sách đó trong hình ảnh nhà cung cấp.

Trong Android 8.0 trở lên, chính sách tồn tại ở các vị trí sau trong AOSP:

  • hệ thống/sepolicy/công khai . Bao gồm chính sách được xuất để sử dụng trong chính sách dành riêng cho nhà cung cấp. Mọi thứ đều được đưa vào cơ sở hạ tầng tương thích Android 8.0. Chính sách công khai được duy trì xuyên suốt các bản phát hành để bạn có thể bao gồm mọi thứ /public trong chính sách tùy chỉnh của mình. Vì điều này, loại chính sách có thể được đặt trong /public sẽ bị hạn chế hơn. Hãy coi đây là API chính sách đã xuất của nền tảng: Mọi thứ liên quan đến giao diện giữa /system/vendor đều thuộc về đây.
  • hệ thống/sepolicy/riêng tư . Bao gồm chính sách cần thiết cho hoạt động của hình ảnh hệ thống, nhưng chính sách hình ảnh của nhà cung cấp không được biết đến.
  • hệ thống/sepolicy/nhà cung cấp . Bao gồm chính sách dành cho các thành phần nằm trong /vendor nhưng tồn tại trong cây nền tảng cốt lõi (không phải thư mục dành riêng cho thiết bị). Đây là sự khác biệt của hệ thống xây dựng giữa các thiết bị và các thành phần chung; về mặt khái niệm, đây là một phần của chính sách dành riêng cho thiết bị được mô tả bên dưới.
  • thiết bị/ manufacturer / device-name /sepolicy . Bao gồm chính sách dành riêng cho thiết bị. Cũng bao gồm các tùy chỉnh thiết bị cho chính sách, trong Android 8.0 trở lên tương ứng với chính sách dành cho các thành phần trên hình ảnh nhà cung cấp.

Trong Android 11 trở lên, phân vùng system_ext và phân vùng sản phẩm cũng có thể bao gồm các chính sách dành riêng cho phân vùng. Chính sách system_ext và sản phẩm cũng được chia thành công khai và riêng tư, đồng thời nhà cung cấp có thể sử dụng chính sách công khai của system_ext và sản phẩm, như chính sách hệ thống.

  • SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS . Bao gồm chính sách được xuất để sử dụng trong chính sách dành riêng cho nhà cung cấp. Đã cài đặt vào phân vùng system_ext.
  • SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS . Bao gồm chính sách cần thiết cho hoạt động của hình ảnh system_ext, nhưng chính sách hình ảnh của nhà cung cấp không được biết đến. Đã cài đặt vào phân vùng system_ext.
  • PRODUCT_PUBLIC_SEPOLICY_DIRS . Bao gồm chính sách được xuất để sử dụng trong chính sách dành riêng cho nhà cung cấp. Đã cài đặt vào phân vùng sản phẩm.
  • PRODUCT_PRIVATE_SEPOLICY_DIRS . Bao gồm chính sách cần thiết cho chức năng của hình ảnh sản phẩm, nhưng chính sách về hình ảnh của nhà cung cấp không được biết đến. Đã cài đặt vào phân vùng sản phẩm.
Lưu ý: khi sử dụng GSI, các phân vùng sản phẩm và system_ext của OEM sẽ không được gắn kết. Các quy tắc trong chính sách riêng biệt của nhà cung cấp sử dụng chính sách chung về sản phẩm và system_ext của OEM sẽ trở thành NOP vì thiếu định nghĩa loại dành riêng cho OEM.
Lưu ý: Hãy hết sức cẩn thận khi sử dụng các chính sách công khai của system_ext và sản phẩm. Chính sách công đóng vai trò là API được xuất giữa system_ext/product và nhà cung cấp. Các đối tác có nghĩa vụ phải tự mình quản lý các vấn đề về khả năng tương thích.

Các kịch bản chính sách được hỗ trợ

Trên các thiết bị chạy Android 8.0 trở lên, hình ảnh nhà cung cấp phải hoạt động với hình ảnh hệ thống OEM và hình ảnh hệ thống AOSP tham chiếu do Google cung cấp (và chuyển CTS trên hình ảnh tham chiếu này). Những yêu cầu này đảm bảo sự tách biệt rõ ràng giữa khung và mã nhà cung cấp. Các thiết bị như vậy hỗ trợ các tình huống sau.

tiện ích mở rộng chỉ dành cho hình ảnh của nhà cung cấp

Ví dụ : Thêm một dịch vụ mới vào vndservicemanager từ hình ảnh nhà cung cấp hỗ trợ các quy trình từ hình ảnh nhà cung cấp.

Giống như các thiết bị khởi chạy cùng phiên bản Android trước, hãy thêm tùy chỉnh dành riêng cho thiết bị trong device/ manufacturer / device-name /sepolicy . Chính sách mới quản lý cách các thành phần của nhà cung cấp tương tác với (chỉ) các thành phần của nhà cung cấp khác sẽ liên quan đến các loại chỉ có trong device/ manufacturer / device-name /sepolicy . Chính sách được viết ở đây cho phép mã của nhà cung cấp hoạt động, sẽ không được cập nhật như một phần của OTA chỉ dành cho khung và sẽ có trong chính sách kết hợp trên thiết bị có hình ảnh hệ thống AOSP tham chiếu.

hỗ trợ hình ảnh nhà cung cấp để làm việc với AOSP

Ví dụ : Thêm một quy trình mới (đã đăng ký với hwservicemanager từ hình ảnh nhà cung cấp) triển khai HAL do AOSP xác định.

Giống như các thiết bị khởi chạy bằng phiên bản Android trước, hãy thực hiện tùy chỉnh dành riêng cho thiết bị trong device/ manufacturer / device-name /sepolicy . Chính sách được xuất dưới dạng một phần của system/sepolicy/public/ có sẵn để sử dụng và được cung cấp như một phần của chính sách của nhà cung cấp. Các loại và thuộc tính từ chính sách công có thể được sử dụng trong các quy tắc mới quy định các tương tác với các bit mới dành riêng cho nhà cung cấp, tuân theo các hạn chế neverallow được cung cấp. Giống như trường hợp chỉ dành cho nhà cung cấp, chính sách mới ở đây sẽ không được cập nhật như một phần của OTA chỉ dành cho khung và sẽ có trong chính sách kết hợp trên thiết bị có hình ảnh hệ thống AOSP tham chiếu.

tiện ích mở rộng chỉ có hình ảnh hệ thống

Ví dụ : Thêm một dịch vụ mới (đã đăng ký với servicemanager) chỉ được truy cập bởi các tiến trình khác từ hình ảnh hệ thống.

Thêm chính sách này vào system/sepolicy/private . Bạn có thể thêm các quy trình hoặc đối tượng bổ sung để kích hoạt chức năng trong hình ảnh hệ thống đối tác, miễn là các bit mới đó không cần tương tác với các thành phần mới trên hình ảnh nhà cung cấp (cụ thể, các quy trình hoặc đối tượng đó phải hoạt động đầy đủ mà không có chính sách từ hình ảnh nhà cung cấp) . Chính sách được xuất theo system/sepolicy/public có sẵn ở đây giống như chính sách dành cho tiện ích mở rộng chỉ dành cho hình ảnh của nhà cung cấp. Chính sách này là một phần của hình ảnh hệ thống và có thể được cập nhật trong OTA chỉ dành cho khung nhưng sẽ không xuất hiện khi sử dụng hình ảnh hệ thống AOSP tham chiếu.

tiện ích mở rộng hình ảnh nhà cung cấp phục vụ các thành phần AOSP mở rộng

Ví dụ: Một HAL mới, không phải AOSP để sử dụng cho các máy khách mở rộng cũng tồn tại trong ảnh hệ thống AOSP (chẳng hạn như system_server mở rộng).

Chính sách tương tác giữa hệ thống và nhà cung cấp phải được đưa vào thư device/ manufacturer / device-name /sepolicy được gửi trên phân vùng của nhà cung cấp. Điều này tương tự với kịch bản ở trên về việc thêm hỗ trợ hình ảnh nhà cung cấp để hoạt động với hình ảnh AOSP tham chiếu, ngoại trừ các thành phần AOSP đã sửa đổi cũng có thể yêu cầu chính sách bổ sung để hoạt động đúng cách với phần còn lại của phân vùng hệ thống (điều này ổn miễn là chúng vẫn hoạt động bình thường). có nhãn loại AOSP công khai).

Chính sách tương tác giữa các thành phần AOSP công khai với các tiện ích mở rộng chỉ có hình ảnh hệ thống phải có trong system/sepolicy/private .

tiện ích mở rộng hình ảnh hệ thống chỉ truy cập giao diện AOSP

Ví dụ: Một quy trình hệ thống mới, không phải AOSP phải truy cập HAL mà AOSP dựa vào.

Điều này tương tự với ví dụ về tiện ích mở rộng chỉ có hình ảnh hệ thống , ngoại trừ các thành phần hệ thống mới có thể tương tác trên giao diện system/vendor . Chính sách cho thành phần hệ thống mới phải có trong system/sepolicy/private , điều này có thể chấp nhận được miễn là thông qua giao diện đã được AOSP thiết lập trong system/sepolicy/public (tức là có các loại và thuộc tính cần thiết cho chức năng). Mặc dù chính sách có thể được bao gồm trong chính sách dành riêng cho thiết bị, nhưng chính sách đó sẽ không thể sử dụng các loại system/sepolicy/private khác hoặc thay đổi (theo bất kỳ cách nào ảnh hưởng đến chính sách) do bản cập nhật chỉ dành cho khung. Chính sách có thể được thay đổi trong OTA chỉ có khung nhưng sẽ không xuất hiện khi sử dụng hình ảnh hệ thống AOSP (cũng sẽ không có thành phần hệ thống mới).

tiện ích mở rộng hình ảnh nhà cung cấp phục vụ các thành phần hệ thống mới

Ví dụ: Thêm một HAL mới, không phải AOSP để quy trình khách sử dụng mà không có chất tương tự AOSP (và do đó yêu cầu tên miền riêng của nó).

Tương tự như ví dụ về tiện ích mở rộng AOSP , chính sách tương tác giữa hệ thống và nhà cung cấp phải nằm trong thư mục device/ manufacturer / device-name /sepolicy được gửi trên phân vùng của nhà cung cấp (để đảm bảo chính sách hệ thống không có kiến ​​thức về chi tiết cụ thể của nhà cung cấp). Bạn có thể thêm các loại công khai mới mở rộng chính sách trong system/sepolicy/public ; việc này chỉ nên được thực hiện ngoài chính sách AOSP hiện có, tức là không xóa chính sách công AOSP. Sau đó, các loại công khai mới có thể được sử dụng cho chính sách trong system/sepolicy/private và trong device/ manufacturer / device-name /sepolicy .

Hãy nhớ rằng mọi bổ sung vào system/sepolicy/public sẽ làm tăng thêm độ phức tạp bằng cách đưa ra một bảo đảm tương thích mới phải được theo dõi trong tệp ánh xạ và phải tuân theo các hạn chế khác. Chỉ các loại mới và quy tắc cho phép tương ứng mới có thể được thêm vào system/sepolicy/public ; các thuộc tính và các tuyên bố chính sách khác không được hỗ trợ. Ngoài ra, các loại công khai mới không thể được sử dụng để gắn nhãn trực tiếp cho các đối tượng trong chính sách /vendor .

Các trường hợp chính sách không được hỗ trợ

Các thiết bị chạy Android 8.0 trở lên không hỗ trợ các ví dụ và kịch bản chính sách sau đây.

Các tiện ích mở rộng bổ sung cho hình ảnh hệ thống cần có quyền đối với các thành phần hình ảnh nhà cung cấp mới sau OTA chỉ dành cho khung

Ví dụ: Một quy trình hệ thống mới không phải AOSP, yêu cầu tên miền riêng, được thêm vào bản phát hành Android tiếp theo và cần quyền truy cập vào HAL mới, không phải AOSP.

Tương tự như tương tác giữa các thành phần của nhà cung cấp và hệ thống (không phải AOSP) , ngoại trừ loại hệ thống mới được giới thiệu trong OTA chỉ dành cho khung. Mặc dù loại mới có thể được thêm vào chính sách trong system/sepolicy/public nhưng chính sách nhà cung cấp hiện tại không biết về loại mới vì nó chỉ theo dõi chính sách công khai của hệ thống Android 8.0. AOSP xử lý vấn đề này bằng cách hiển thị các tài nguyên do nhà cung cấp cung cấp thông qua một thuộc tính (ví dụ: thuộc tính hal_foo ) nhưng vì tiện ích mở rộng đối tác thuộc tính không được hỗ trợ trong system/sepolicy/public nên phương pháp này không khả dụng đối với chính sách của nhà cung cấp. Quyền truy cập phải được cung cấp bởi loại công khai đã tồn tại trước đó.

Ví dụ: Một thay đổi đối với quy trình hệ thống (AOSP hoặc không phải AOSP) phải thay đổi cách nó tương tác với thành phần nhà cung cấp mới, không phải AOSP.

Chính sách trên hình ảnh hệ thống phải được viết mà không cần biết về các tùy chỉnh cụ thể của nhà cung cấp. Do đó, chính sách liên quan đến các giao diện cụ thể trong AOSP được hiển thị thông qua các thuộc tính trong hệ thống/sepolicy/công khai để chính sách của nhà cung cấp có thể chọn tham gia vào chính sách hệ thống trong tương lai sử dụng các thuộc tính này. Tuy nhiên, các phần mở rộng thuộc tính trong system/sepolicy/public không được hỗ trợ , vì vậy tất cả chính sách quy định cách các thành phần hệ thống tương tác với các thành phần nhà cung cấp mới (và không được xử lý bởi các thuộc tính đã có trong AOSP system/sepolicy/public ) phải có trong device/ manufacturer / device-name /sepolicy . Điều này có nghĩa là các loại hệ thống không thể thay đổi quyền truy cập được phép đối với các loại nhà cung cấp như một phần của OTA chỉ dành cho khung.