Tuỳ chỉnh SELinux

Sau khi bạn đã tích hợp cấp cơ sở của chức năng SELinux và bạn có thể 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 để bao gồm các tuỳ 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 Chương trình tương thích với Android các yêu cầu và không được xoá 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, chúng nguy cơ phá vỡ quy trình triển khai Android SELinux và các ứng dụng mà nó chi phối. Điều này áp dụng cho cả các ứng dụng bên thứ ba có thể sẽ cần được đã được cải thiện sao cho tuân thủ và vận hành. Ứ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 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 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 (Dự án nguồn mở Android)

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 người dùng cuối
• Cho phép tuỳ chỉnh chính sách MDM
• Lừa đảo người dùng vi phạm chính sách
• Thêm cửa sau

Xem phần Các tính năng bảo mật kernel của Android Tài liệu Định nghĩa về khả năng tương thích để 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 nêu rõ ràng được phép trong chính sách. Vì SELinux mặc định của Android đã hỗ trợ Dự án nguồn mở Android, bạn không bắt buộc phải sửa đổi 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:

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

Sau khi bạn tích hợp thay đổi chính sách SELinux, hãy thêm một bước vào để đảm bảo khả năng tương thích với SELinux trong tương lai. Lý tưởng quá trình phát triển phần mềm, chính sách SELinux chỉ thay đổi khi phần mềm các thay đổi về mô hình chứ không phải là 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 vào 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ư bất kỳ chính sách liên quan nào được tạo bởi OEM trước khi bật chế độ thực thi.

Để ngăn chặn các vấn đề không cần thiết, bạn nên sử dụng chiến dịch ở phạm vi rộng và tương thích quá mức so với quá hạn chế và không tương thích, dẫn đến lỗi chức năng của thiết bị. Ngược lại, nếu những thay đổi của bạn có lợi cho người khác, thì bạn nên gửi nội dung 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á bị 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 bằng mỗi bản phát hành Android mới.

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

SELinux dựa trên M4 ngôn ngữ máy tính và do đó hỗ trợ nhiều macro khác nhau để 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 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ó thể viết tương tự câu lệnh này bằng SELinux *_file_perms macro (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;

Chính sách mẫu

Dưới đâ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 cùng phân tích ví dụ sau:

Trong dòng đầu tiên, phần khai báo loại, daemon DHCP kế thừa từ chính sách bảo mật cơ sở (domain). Từ tuyên bố trước Ví dụ: DHCP có thể đọc và ghi vào /dev/null.

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

Trong dòng init_daemon_domain(dhcp), chính sách nêu rõ DHCP là được tạo ra từ init và được phép giao tiếp với nguồn cấp dữ liệu này.

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ổng và tiến hành DNS yêu cầu.

Trong 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 minh hoạ Gắn nhãn tệp chi tiết của SELinux. Hàm này sử dụng nhãn proc_net để giới hạn quyền ghi chỉ 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 ứng dụng có thể được phép tương tác với nhau. Chính sách cho biết DHCP và netd có thể giao tiếp với với nhau thông qua chỉ số mô tả tệp, tệp FIFO, cổng gói dữ liệu và luồng UNIX ổ cắm. DHCP chỉ có thể đọc và ghi từ cổng gói tin và UNIX phát trực tuyến và không tạo hoặc mở chúng.

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

ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton

add_name remove_name reparent search rmdir open audit_access execmod

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

mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget

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

compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy

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

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

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

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

Quy tắc 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Xem trang thông tin về ptrace. sys_ptrace cung cấp khả năng ptrace bất kỳ quy trình nào, cho phép quyền kiểm soát đối với các quá trình khác và chỉ nên thuộc về hệ thống được chỉ định thành phần, được nêu trong quy tắc. Nhu cầu có khả năng này thường cho thấy sự hiện diện của nội dung nào đó không dành cho 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ể, phương thức 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 tính bảo mật nhờ các cơ chế như xác minh quy trình khởi động. Thông thường, giải pháp tốt nhất khi gặp sự cố về Quy tắc neverallow là di chuyển mã vi phạm sang phần Phân vùng /system.

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

Phần này đưa ra nguyên tắc cho chính sách SELinux của nhà cung cấp trong Android 8.0 và cao hơn, bao gồm cả thông tin chi tiết về Dự án nguồn mở Android (AOSP) SEPolicy và Tiện ích SEPolicy. Để biết thêm thông tin về cách giữ chính sách SELinux 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.

Đặ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. Trong Android 8.0 trở lên, việc thêm chính sách vào BOARD_SEPOLICY_DIRS chỉ đặt chính sách này trong nhà cung cấp hình ảnh.

Trên Android 8.0 trở lên, chính sách có ở các vị trí sau trong AOSP:

• system/sepolicy/public. Bao gồm chính sách đã xuất để sử dụng trong chính sách dành riêng cho nhà cung cấp. Mọi thứ đều đi vào Android 8.0 cơ sở hạ tầng tương thích. Chính sách công khai được duy trì trong các bản phát hành để bạn có thể đưa vào bất kỳ /public nào trong chính sách tuỳ chỉnh của bạn. Do đó, loại chính sách có thể đặt trong /public sẽ bị hạn chế. Hãy xem xét API chính sách đã xuất của nền tảng: Bất cứ điều gì xử lý giao diện giữa /system và /vendor thuộc về đâ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, mà chính sách về hình ảnh của nhà cung cấp chưa có kiến thức.
• system/sepolicy/vendor. Có chính sách về 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à cấu phần phần mềm của sự khác biệt giữa thiết bị và các thành phần chung; về mặt lý thuyết thì đây là chính sách dành riêng cho từng thiết bị được mô tả bên dưới.
• device/manufacturer/device-name/sepolicy. Bao gồm cả chính sách dành riêng cho từng thiết bị. Bao gồm cả các tuỳ chỉnh thiết bị để . Chính sách này trong Android 8.0 trở lên tương ứng với chính sách về các thành phần trên hình ảnh của nhà cung cấp.

Trong Android 11 trở lên, 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. system_ext và chính sách 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 thuộc tính công khai của system_ext 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 cho 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 hình ảnh nhà cung cấp chính sách của bạn nên 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 cho 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 hoạt động của chính sách hình ảnh của nhà cung cấp chưa có kiến thức. Đã cài đặt vào phân vùng sản phẩm.

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

phần mở rộng chỉ hiển thị hình ảnh của nhà cung cấp

Ví dụ: Thêm 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ư với các thiết bị chạy phiên bản Android trước đó, hãy thêm 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 nhà cung cấp khác các thành phần 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 tại đây sẽ cho phép mã của nhà cung cấp hoạt động, sẽ không được cập nhật dưới dạng một phần của một OTA chỉ có khung và sẽ xuất hiện trong chính sách kết hợp trên thiết bị với hình ảnh hệ thống AOSP tham chiếu.

dịch vụ hỗ trợ hình ảnh nhà cung cấp để hoạt động bằng AOSP (Dự án nguồn mở Android)

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

Giống như với các thiết bị chạy phiên bản Android trước, hãy thực hiện của riêng thiết bị trong device/manufacturer/device-name/sepolicy. Hiện đã có chính sách được xuất trong system/sepolicy/public/ để sử dụng và được vận chuyển theo chính sách của nhà cung cấp. Loại và thuộc tính của chính sách công khai đó có thể được sử dụng trong các quy tắc mới ra lệnh tương tác với thông tin cụ thể về nhà cung cấp, tuân theo neverallow được cung cấp hạn chế. Giố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 như một phần của OTA chỉ có khung và sẽ xuất hiện 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 chỉ dành cho hình ảnh hệ thống

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

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

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

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

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

hình ảnh hệ thống các tiện ích chỉ truy cập giao diện AOSP (Dự án nguồn mở Android)

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

Thuộc tính này tương tự như thuộc tính system-image-only ví dụ về tiện ích, 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 hãy truy cập vào 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 (tức là các loại và thuộc tính bắt buộc đối với chức năng nào có sẵn). Mặc dù chính sách có thể được đưa vào chính sách dành riêng cho từng thiết bị chính sách khác, thì bạn sẽ không thể sử dụng 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 chỉ cập nhật. Chính sách có thể được thay đổi trong OTA chỉ trong khung, nhưng sẽ không hiển thị khi sử dụng hình ảnh hệ thống AOSP (không có hệ thống mới) thành phần).

hình ảnh nhà cung cấp tiện ích phân phát các thành phần hệ thống mới

Ví dụ: Thêm một lớp trừu tượng phần cứng (HAL) mới, không phải của AOSP (Dự án nguồn mở Android) để quy trình ứng dụng sử dụng không có phiên bản tương tự AOSP (và do đó yêu cầu miền riêng của nó).

Tương tự như phần mở rộng AOSP (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 đưa vào device/manufacturer/device-name/sepolicy thư mục được vận chuyển trên phân vùng nhà cung cấp (để đảm bảo chính sách hệ thống không biết thông tin chi tiết cụ thể về 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; bạn chỉ nên thực hiện việc này ngoài việc chính sách AOSP hiện có, tức là không xoá chính sách công khai của AOSP (Dự án nguồn mở Android). Thông tin công khai mới sau đó có thể được sử dụng cho chính sách trong system/sepolicy/private và trong device/manufacturer/device-name/sepolicy

Xin lưu ý rằng mọi thao tác thêm vào system/sepolicy/public đều sẽ thêm bằng cách đưa ra một đảm bảo tương thích mới cần theo dõi trong một tệp ánh xạ và có các hạn chế khác. Chỉ các loại mới và bạn có thể thêm các quy tắc cho phép tương ứng vào system/sepolicy/public; và các tuyên bố chính sách khác không được hỗ trợ. Ngoài ra, tính năng mới Bạn không thể dùng loại công khai để gắn nhãn trực tiếp đố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 tính năng sau chính sách và ví dụ.

Thông tin khác tiện ích mở rộng đến hình ảnh hệ thống cần được cấp quyền vào thành phần hình ảnh nhà cung cấp mới sau OTA chỉ khung

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

Tương tự với mới Tương tác của các thành phần của hệ thống và nhà cung cấp (không phải AOSP), ngoại trừ hệ thống mới được đưa ra trong một OTA chỉ có khung. Mặc dù có thể thêm loại mới vào chính sách theo system/sepolicy/public, chính sách hiện tại của nhà cung cấp không có thông tin thuộc loại mới vì chỉ theo dõi chính sách công khai của hệ thống Android 8.0. AOSP xử lý việc này bằng cách hiển thị tài nguyên do nhà cung cấp cung cấp thông qua một thuộc tính (ví dụ: hal_foo) nhưng vì phần mở rộng của đối tác thuộc tính thì không được hỗ trợ trong system/sepolicy/public, nên phương pháp này không áp dụng được 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ụ: 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 mới của nhà cung cấp không phải AOSP (Dự án nguồn mở Android).

Chính sách về hình ảnh hệ thống phải được viết mà không có kiến thức cụ thể phần tuỳ chỉnh của nhà cung cấp. Do đó, chính sách liên quan đến các giao diện cụ thể trong AOSP (Dự án nguồn mở Android) đượ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 tham gia chính sách hệ thống trong tương lai có sử dụng các thuộc tính này. Tuy nhiên, phần mở rộng về thuộc tính trong system/sepolicy/public không được hỗ trợ, vì vậy, mọi chính sách chỉ dẫn cách các thành phần hệ thống tương tác với các thành phần mới của nhà cung cấp (và các thành phần này hiện chưa được các thuộc tính xử lý) có trong AOSP system/sepolicy/public) phải ở device/manufacturer/device-name/sepolicy. Điều này có nghĩa là loại hệ thống không thể thay đổi quyền truy cập được phép vào các loại nhà cung cấp trong khuôn khổ OTA chỉ dành cho khung.