Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Trang này được dịch bởi Cloud Translation API.

Tuỳ chỉnh SELinux

Sau khi tích hợp chức năng SELinux ở cấp cơ sở và phân tích kỹ kết quả, bạn có thể thêm các chế độ cài đặt chính sách riêng để đưa các chế độ tuỳ chỉnh vào 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 xoá chế độ cài đặt SELinux mặc định.

Nhà sản xuất không được xoá chính sách SELinux hiện có. Nếu không, các ứng dụng này có nguy cơ phá vỡ quá trình triển khai Android SELinux và các ứng dụng mà nó quản lý. Trong đó có cả các ứng dụng bên thứ ba có thể cần được cải thiện để tuân thủ chính sách và hoạt động đượ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 đầu tuỳ chỉnh SELinux, hãy nhớ:

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

Và đừng quên:

Tạo chính sách không tương thích
Cho phép tuỳ chỉnh chính sách cho người dùng cuối
Cho phép tuỳ chỉnh chính sách MDM
Sợ hãi người dùng bằng các lỗi vi phạm chính sách
Thêm cửa sau

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

SELinux sử dụng phương pháp 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 thì mới được cấp. Vì chính sách SELinux mặc định của Android đã hỗ trợ Dự án nguồn mở Android, nên bạn không bắt buộc phải sửa đổi chế độ cài đặt SELinux theo bất kỳ cách nào. Nếu bạn tuỳ chỉnh chế độ cài đặt SELinux, hãy thật cẩn thận để không làm hỏng các ứng dụng hiện có. Cách bắt đầu:

Sử dụng hạt nhân Android mới nhất.
Áp dụng nguyên tắc đặc quyền tối thiểu.
Chỉ giải quyết những nội dung bổ sung của riêng bạn cho Android. Chính sách mặc định sẽ tự động hoạt động với cơ sở mã Dự án nguồn mở Android.
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 tác vụ riêng lẻ.
Tạo chính sách SELinux để tách biệt các tác vụ đó với các hàm không liên quan.
Đặt các chính sách đó vào các tệp *.te (tiện ích 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 vào bản dựng của bạn.
ban đầu, hãy cho phép các miền mới. Bạn có thể thực hiện việc này bằng cách sử dụng nội dung khai báo cho phép trong tệp .te của miền.
Phân tích kết quả và tinh chỉnh định nghĩa miền.
Xoá nội dung khai báo cho phép khi không có nội dung từ chối nào khác xuất hiện trong các bản dựng userdebug.

Sau khi tích hợp thay đổi chính sách SELinux, hãy thêm một bước vào quy trình phát triển để đảm bảo khả năng tương thích với 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 cách triển khai thực tế.

Khi bạn bắt đầu tuỳ chỉnh SELinux, trước tiên, hãy kiểm tra các nội dung bổ sung của bạn cho Android. Nếu bạn đã thêm một thành phần tiến hành một hàm 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 (Nhà sản xuất thiết bị gốc) tạo, trước khi bật chế độ thực thi.

Để ngăn chặn các vấn đề không cần thiết, tốt hơn là bạn nên đặt một vị trí quá rộng và tương thích quá mức, thay vì quá hạn chế và không tương thích (dẫn đến các chức năng của thiết bị bị hỏng). Ngược lại, nếu các thay đổi của bạn sẽ mang lại lợi ích cho người khác, bạn nên gửi nội dung sửa đổi cho 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, thì bạn sẽ không cần thực hiện thay đổi này với từng bản phát hành Android mới.

Ví dụ về tuyên bố chính sách

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

Trong ví dụ sau, tất cả miền đều được cấp quyền đọc từ 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 };

Bạn cũng có thể viết cùng một câu lệnh này bằng các macro *_file_perms của SELinux (viết tắt):

# 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;

Ví dụ về chính sách

Dưới đây là chính sách mẫu đầy đủ cho DHCP mà chúng ta sẽ xem xét:

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 phân tích ví dụ này:

Trong dòng đầu tiên, phần khai báo loại, 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ụ về câu lệnh trước, DHCP có thể đọc và ghi vào /dev/null.

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

Trong dòng init_daemon_domain(dhcp), chính sách cho biết DHCP được tạo ra từ init và được phép giao tiếp với DHCP.

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

Trong dòng allow dhcp proc_net:file write;, chính sách cho biết rằng DHCP có thể ghi vào các tệp cụ thể trong /proc. Dòng này minh hoạ việc gắn nhãn tệp chi tiết của SELinux. Phương thức này sử dụng nhãn proc_net để chỉ giới hạn quyền 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 chỉ số 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 mà không thể tạo hoặc mở các ổ cắm đó.

Chế độ kiểm soát hiện có

Lớp	Quyền
tệp	ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton
thư 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	mount remount unmount getattr relabelfrom relabelto transition associate quotamod quotaget
quy 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
nguồn tài trợ	compute_av compute_create compute_member check_context load_policy compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot read_policy
chức 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
XEM THÊM	VÀ NHIỀU TÍNH NĂNG KHÁC

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ờ được xảy ra. Với tính năng kiểm thử 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ị.

Các nguyên tắc sau đây nhằm giúp nhà sản xuất tránh các lỗi liên quan đến quy tắc neverallow trong quá trình tuỳ chỉnh. 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 về ptrace. Chức năng sys_ptrace cho phép ptrace bất kỳ quy trình nào, cho phép kiểm soát tốt các quy trình khác và chỉ nên thuộc về các thành phần hệ thống được chỉ định, như đã nêu trong quy tắc. Nhu cầu về chức năng này thường cho thấy sự hiện diện của một nội dung không dành cho các bản dựng dành cho người dùng hoặc chức năng không cần thiết. Xoá 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 dùng để ngăn việc thực thi mã tuỳ ý trên hệ thống. Cụ thể, mã này xác nhận rằng chỉ mã trên /system mới được thực thi, cho phép đảm bảo bảo mật nhờ các cơ chế như khởi động đã xác minh. Thường thì 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.

Tuỳ chỉnh SEPolicy trong Android 8.0 trở lên

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

Vị trí đặt chính sách

Trong Android 7.0 trở xuống, 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 (Dự án nguồn mở Android) trên các loại thiết bị khác nhau. Trên 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 này 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:

system/sepolicy/public. 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 của Android 8.0. Chính sách công khai được duy trì trên các bản phát hành để bạn có thể đưa mọi /public vào chính sách tuỳ chỉnh. Do đó, loại chính sách có thể đặ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 và /vendor đều thuộc về API này.
system/sepolicy/private. 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 không bao gồm chính sách hình ảnh của nhà cung cấp.
system/sepolicy/vendor. Bao gồm chính sách cho các thành phần đi vào /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à một cấu phần phần mềm của sự khác biệt giữa thiết bị và thành phần toàn cục trong hệ thống xây dựng; 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.
device/manufacturer/device-name/sepolicy. Bao gồm chính sách dành riêng cho thiết bị. Ngoài ra, còn bao gồm các tuỳ chỉnh thiết bị cho chính sách. Trong Android 8.0 trở lên, chính sách này tương ứng với chính sách cho các thành phần trên hình ảnh của nhà cung cấp.

Trong Android 11 trở lên, các phân vùng system_ext và 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. Các 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 các chính sách công khai của system_ext và sản phẩm, chẳng hạn 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 không có kiến thức về chính sách hình ảnh của nhà cung cấp. Đã 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 hoạt động của hình ảnh sản phẩm, nhưng không bao gồm chính sách hình ảnh của nhà cung cấp. Đã 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 system_ext và sản phẩm của OEM sẽ không được gắn. Các quy tắc trong chính sách bảo mật của nhà cung cấp sử dụng chính sách công khai sản phẩm và system_ext của OEM sẽ trở thành NOP do thiếu định nghĩa loại dành riêng cho OEM.

Lưu ý: Hãy đặc biệt cẩn thận khi sử dụng system_ext và các chính sách công khai về sản phẩm. Chính sách công khai đóng vai trò là API đã xuất giữa system_ext/product và nhà cung cấp. Đối tác phải tự quản lý các vấn đề về khả năng tương thích.

Các tình huống 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à truyền CTS vào hình ảnh tham chiếu này). Các yêu cầu này đảm bảo sự tách biệt rõ ràng giữa khung và mã của nhà cung cấp. Những thiết bị như vậy hỗ trợ các trường hợp sau.

phần mở rộng chỉ hiển thị 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.

Cũng như các thiết bị chạy các phiên bản Android trước, hãy thêm tuỳ chỉnh dành riêng cho thiết bị trong device/manufacturer/device-name/sepolicy. Chính sách mới quy định cách các thành phần của nhà cung cấp tương tác (chỉ) với các thành phần khác của nhà cung cấp chỉ nên liên quan đến các loại 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 trong bản OTA chỉ dành cho khung và 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 của nhà cung cấp để hoạt động với AOSP

Ví dụ: Thêm một quy trình mới (được đăng ký bằng 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ị chạy phiên bản Android trước đó, hãy tuỳ chỉnh theo thiết bị cụ thể trong device/manufacturer/device-name/sepolicy. Bạn có thể sử dụng chính sách được xuất trong system/sepolicy/public/ và chính sách này được vận chuyển trong chính sách của nhà cung cấp. Bạn có thể sử dụng các loại và thuộc tính của chính sách công khai trong các quy tắc mới để ra lệnh 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 quy định hạn chế về neverallow được cung cấp. Cũng như trường hợp chỉ dành cho nhà cung cấp, chính sách mới tại đây sẽ không được cập nhật trong bản OTA chỉ dành cho khung và 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.

các phần mở rộng chỉ dành cho hình ảnh hệ thống

Ví dụ: Thêm một dịch vụ mới (đã đăng ký bằng servicemanager) mà chỉ được các quy trình khác truy cập 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 để bật chức năng trong ảnh hệ thống của đố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 ảnh nhà cung cấp (cụ thể là các quy trình hoặc đối tượng đó phải đầy đủ chức năng mà không cần có chính sách từ hình ảnh nhà cung cấp). Chính sách do system/sepolicy/public xuất có sẵn tại đây giống như chính sách cho các tiện ích chỉ có 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 có khi sử dụng hình ảnh hệ thống AOSP tham chiếu.

phần mở rộng hình ảnh của nhà cung cấp phân phát các thành phần AOSP mở rộng

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

Chính sách về hoạt động tương tác giữa hệ thống và nhà cung cấp phải được đưa vào thư mục device/manufacturer/device-name/sepolicy được vận chuyển trên phân vùng nhà cung cấp. Điều này tương tự như trường hợp thêm tính năng hỗ trợ hình ảnh nhà cung cấp ở trên để hoạt động với hình ảnh AOSP (Dự án nguồn mở Android) 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 (miễn là chúng vẫn có nhãn loại AOSP công khai).

Chính sách tương tác của các thành phần AOSP công khai với các tiện ích chỉ dành cho hình ảnh hệ thống phải nằm trong system/sepolicy/private.

các tiện ích hình ảnh hệ thống chỉ truy cập vào 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 vào HAL mà AOSP dựa vào.

Việc này tương tự như ví dụ về tiện ích chỉ 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 nằm trong system/sepolicy/private, được chấp nhận miễn là thông qua một giao diện đã được AOSP thiết lập trong system/sepolicy/public (nghĩa 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 đưa vào chính sách dành riêng cho thiết bị, nhưng chính sách này sẽ không thể sử dụng các loại system/sepolicy/private hoặc thay đổi khác (trong mọi trường hợp có ảnh hưởng đến chính sách) do bản cập nhật chỉ dành cho khung. Chính sách này có thể được thay đổi trong bản cập nhật 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 (cũng sẽ không có thành phần hệ thống mới).

phần mở rộng hình ảnh của nhà cung cấp phân phát 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 để một quy trình ứng dụng sử dụng mà không có AOSP tương tự (do đó yêu cầu miền riêng).

Tương tự như ví dụ về phần mở rộng AOSP, chính sách về hoạt động 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 vận chuyển 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ó thông tin về chi tiết dành riêng cho 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 xoá chính sách công khai AOSP. Sau đó, bạn có thể sử dụng các loại công khai mới cho chính sách trong system/sepolicy/private và trong device/manufacturer/device-name/sepolicy.

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

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

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

Các tiện ích bổ sung cho hình ảnh hệ thống cần có quyền truy cập vào các thành phần hình ảnh của nhà cung cấp mới sau khi chỉ có OTA khung

Ví dụ: Một quy trình hệ thống mới không phải AOSP, yêu cầu 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 một HAL mới, không phải AOSP.

Tương tự như hoạt động tương tác giữa hệ thống mới (không phải AOSP) và các thành phần của nhà cung cấp, ngoại trừ loại hệ thống mới được giới thiệu trong một OTA chỉ dành cho khung. Mặc dù bạn có thể thêm loại mới vào chính sách trong system/sepolicy/public, nhưng chính sách hiện tại của nhà cung cấp không biết về loại mới này vì 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ì các tiện ích đối tác thuộc tính không được hỗ trợ trong system/sepolicy/public, nên phương thức này không áp dụng cho chính sách của nhà cung cấp. Quyền truy cập phải được cung cấp bởi một loại công khai đã có 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 quy trình đó 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 về hình ảnh hệ thống phải được viết mà không cần biết đến các tuỳ 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 system/sepolicy/public để chính sách của nhà cung cấp có thể chọn sử dụng 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 tiện ích 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ằng các thuộc tính hiện có trong system/sepolicy/public AOSP) phải nằm 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 cho các loại nhà cung cấp trong một bản cập nhật OTA chỉ dành cho khung.