Google cam kết thúc đẩy công bằng chủng tộc cho các cộng đồng Đen. Xem thế nào.
Trang này được dịch bởi Cloud Translation API.
Switch to English

Tùy chỉnh SELinux

Sau khi bạn đã tích hợp chức năng cơ bản của chức năng SELinux và phân tích kỹ lưỡng kết quả, bạn có thể thêm các cài đặt chính sách của riêng mình để bao gồm các tùy chỉnh của bạn 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 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ó. Mặt khác, họ có nguy cơ phá vỡ triển khai Android SELinux và các ứng dụng mà nó chi phối. Điều này bao gồm các ứng dụng của bên thứ ba có thể sẽ cần phải được cải thiện để tuân thủ và hoạt động. Các ứng dụng không 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 trình nền 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
  • Gán tên 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 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 đến AOSP

Và 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 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 tùy chỉnh cài đặt SELinux, hãy cẩn thận để không phá vỡ các ứng dụng hiện có. Để bắt đầu:

  1. Sử dụng kernel Android mới nhất .
  2. Áp dụng nguyên tắc đặc quyền tối thiểu .
  3. Địa chỉ chỉ bổ sung của riêng bạn cho Android. Chính sách mặc định hoạt động với cơ sở mã dự án nguồn mở Android .
  4. Sắp xếp 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 để cách ly các tác vụ đó khỏi các hàm không liên quan.
  6. Đặt các chính sách đó vào các tệp *.te (phần mở rộng cho các tệp nguồn chính sách của *.te ) 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. Làm cho tên miền mới cho phép ban đầu. Điều này được thực hiện bằng cách sử dụng khai báo cho phép trong tệp .te của tên 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 khai báo cho phép khi không có từ chối nào xuất hiện trong các bản dựng userdebug.

Sau khi bạn đã tích hợp thay đổi chính sách 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 của 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 của SELinux chỉ thay đổi khi mô hình phần mềm thay đổi và không 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 các vấn đề không cần thiết, tốt hơn là quá mức và tương thích quá mức hơn là 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 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 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, 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.

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

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 tên miền đượ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 };

Tuyên bố tương tự này có thể được viết bằng các macro *_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 ví dụ

Dưới đây là một chính sách ví dụ hoàn chỉnh cho DHCP, mà chúng tôi kiểm tra 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 phân tích ví dụ:

Trong dòng đầu tiên, khai báo kiểu, daemon 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 .

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) , trạng thái chính sách DHCP được sinh ra từ init và được phép giao tiếp với nó.

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 như đọc và ghi các gói TCP, giao tiếp qua các ổ 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 trạng thái DHCP có thể ghi vào các tệp cụ thể trong /proc . Dòng này thể hiện ghi nhãn tập tin chi tiết tốt của SELinux. Nó sử dụng nhãn proc_net để giới hạn quyền truy cập 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 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 các 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 và không tạo hoặc mở chúng.

Kiểm soát có sẵn

Lớp học Giấy phép
tập tin
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ờ

neverallow quy tắc không bao giờ 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 , quy tắc không bao giờ của neverallow hiện được thi hành trên các thiết bị.

Các hướng dẫn sau đây nhằm giúp các nhà sản xuất tránh 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 người đàn ông cho ptrace . Các sys_ptrace khả năng cấp khả năng ptrace bất kỳ quá trình, cho phép rất nhiều quyền kiểm soát các quá trình khác và chỉ nên 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 hoặc chức năng mà người dùng phải đối mặt. Loại bỏ các 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ó khẳng định rằng chỉ có mã trên /system được thực thi, 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, các giải pháp tốt nhất khi gặp phải một vấn đề với điều này neverallow quy tắc là để di chuyển mã xúc phạm đến /system phân vùng.

Tùy chỉnh SEPolicy trong Android 8.0 trở lên

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

Vị trí chính sách

Trong Android 7.0 trở về trước, cá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 chính sách nhằm tăng cường chính sách AOSP cho 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 đặt chính sách trong hình ảnh của 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 cộng . Bao gồm chính sách xuất khẩu để sử dụng trong chính sách dành riêng cho nhà cung cấp. Mọi thứ đều đi vào cơ sở hạ tầng tương thích Android 8.0. Chính sách công có nghĩa là duy trì trên 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. Do đó, loại chính sách có thể được đặt trong /public bị hạn chế hơn. Hãy xem đây là API chính sách xuất khẩu của nền tảng: Bất kỳ điều gì liên quan đến giao diện giữa /system/vendor thuộc về đây.
  • hệ thống / sepolicy / tư nhân . Bao gồm chính sách cần thiết cho chức năng của hình ảnh hệ thống, nhưng trong đó chính sách hình ảnh của nhà cung cấp sẽ không có kiến ​​thức.
  • hệ thống / sepolicy / nhà cung cấp . 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 tạo tác của 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 toàn cầu; 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 cho các thành phần trên hình ảnh của nhà cung cấp.

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

Trên các thiết bị khởi 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 kịch bản sau đây.

tiện ích mở rộng chỉ dành cho 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 với các phiên bản Android trước đó, hãy thêm tùy chỉnh dành riêng cho device/ manufacturer / device-name /sepolicy trong device/ manufacturer / device-name /sepolicy . Chính sách mới điều chỉnh cách các thành phần nhà cung cấp tương tác với (chỉ) các thành phần nhà cung cấp khác nên 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ã trên nhà cung cấp hoạt động, sẽ không được cập nhật như một phần của OTA chỉ khung và sẽ có mặt 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) thực hiện HAL do AOSP xác định.

Giống như các thiết bị khởi chạy với các phiên bản Android trước đó, hãy thực hiện tùy chỉnh cụ thể theo device/ manufacturer / device-name /sepolicy 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 vận chuyển như một phần của chính sách 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 chỉ ra các tương tác với các bit cụ thể của nhà cung cấp mới, tuân theo các hạn chế không neverallow được cung cấp. Như với 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ư là một phần của OTA chỉ dành cho khung và sẽ có mặt 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.

phần 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 quy 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 của 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 bởi system/sepolicy/public có sẵn ở đây giống như chính sách dành cho các tiện ích mở rộng chỉ dành cho 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 hình ả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 bao gồm trong thư mục device/ manufacturer / device-name /sepolicy được phân phối trên phân vùng 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 của 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 được sửa đổi cũng có thể yêu cầu chính sách bổ sung để hoạt động đúng với phần còn lại của phân vùng hệ thống (vẫn ổn nếu vẫn cò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 cộng với các tiện ích mở rộng chỉ có hình ảnh hệ thống phải ở 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 vào HAL mà AOSP dựa vào.

Điều này tương tự như ví dụ 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 , có thể chấp nhận được với điều kiện là thông qua giao diện đã được AOSP thiết lập trong system/sepolicy/public (nghĩa là các loại và thuộc tính cần thiết cho chức năng đều có). 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 nó sẽ không thể sử dụng các loại system/sepolicy/private khác (theo bất kỳ cách nào ảnh hưởng đến chính sách) do cập nhật chỉ theo khung. Chính sách có thể được thay đổi 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 (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 HOS mới, không phải AOSP để sử dụng cho quy trình khách mà không có 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ề phần mở rộng AOSP , chính sách tương tác giữa hệ thống và nhà cung cấp phải có trong thư mục device/ manufacturer / device-name /sepolicy được phân phối trên phân vùng 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 ; điều 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 cộng AOSP. Các loại 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 .

Hãy nhớ rằng mọi bổ sung cho system/sepolicy/public làm tăng thêm sự phức tạp bằng cách đưa ra một đảm bảo 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 có thể được thêm vào trong 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 .

Kịch bản chính sách không được hỗ trợ

Các thiết bị khởi chạy với 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 sự cho phép đối với các thành phần hình ảnh nhà cung cấp mới sau một OTA chỉ dành cho khung

Ví dụ: Một quy trình hệ thống không phải AOSP mới, yêu cầu tên miền riêng, được thêm vào trong 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ư hệ thống tương tác mới (không phải AOSP) của hệ thống và nhà cung cấp , 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 , chính sách nhà cung cấp hiện tại không có kiến ​​thức 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ý việc 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 mở rộng đối tác thuộc tính không được hỗ trợ trong system/sepolicy/public , phương thức này không có sẵn 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 trước đó.

Ví dụ: Thay đổi quy trình hệ thống (AOSP hoặc không phải AOSP) phải thay đổi cách 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ó kiến ​​thức 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 thể hiện 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 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 chỉ ra cách các thành phần hệ thống tương tác với các thành phần của nhà cung cấp mới (và không được xử lý bởi các thuộc tính đã có trong system/sepolicy/public 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ư là một phần của OTA chỉ dành cho khung.