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.

Khả năng tương thích chính sách

Bài viết này mô tả cách Android xử lý các vấn đề tương thích chính sách với OTA của nền tảng, trong đó cài đặt SELinux nền tảng mới có thể khác với cài đặt SELinux của nhà cung cấp cũ.

Thiết kế chính sách SELinux Treble dựa trên xem xét một sự phân biệt nhị phân giữa nền tảng và chính sách nhà cung cấp; chương trình này trở nên phức tạp hơn nếu phân vùng nhà cung cấp tạo ra phụ thuộc, chẳng hạn như platform < vendor < oem .

Trong Android 8.0 trở lên, chính sách toàn cầu của SELinux được chia thành các thành phần riêng tư và công khai. Các thành phần công khai bao gồm chính sách và cơ sở hạ tầng liên quan, được đảm bảo có sẵn cho phiên bản nền tảng. Chính sách này sẽ được hiển thị cho người viết chính sách nhà cung cấp để cho phép nhà cung cấp xây dựng tệp chính sách nhà cung cấp, tệp này khi được kết hợp với chính sách do nền tảng cung cấp sẽ tạo ra một chính sách đầy đủ chức năng cho một thiết bị.

  • Cho versioning, chính sách nền tảng công xuất khẩu sẽ được viết như là thuộc tính.
  • Để dễ dàng viết chính sách, các loại xuất khẩu sẽ được chuyển thành các thuộc tính là phiên bản như một phần của chính sách quá trình xây dựng. Loại công khai cũng có thể được sử dụng trực tiếp trong các quyết định gắn nhãn do tệp ngữ cảnh của nhà cung cấp cung cấp.

Android duy trì một ánh xạ giữa các loại bê tông xuất khẩu trong chính sách nền tảng và các thuộc tính tương ứng với phiên bản cho mỗi phiên bản nền tảng. Điều này đảm bảo rằng khi các đối tượng được gắn nhãn với một loại, nó không phá vỡ hành vi được đảm bảo bởi chính sách nền tảng-công khai trong phiên bản trước. Lập bản đồ này được duy trì bằng cách giữ một tập tin bản đồ up-to-date cho mỗi phiên bản nền tảng , mà giữ thông tin thành viên thuộc tính cho từng loại xuất khẩu trong chính sách công.

Quyền sở hữu đối tượng và ghi nhãn

Khi tùy chỉnh chính sách trong Android 8.0 trở lên, quyền sở hữu phải được xác định rõ ràng cho từng đối tượng để giữ nền tảng và chính sách nhà cung cấp riêng biệt. Ví dụ, nếu các nhà cung cấp nhãn /dev/foo và nền tảng này sau đó nhãn /dev/foo trong một OTA tiếp theo, sẽ có hành vi không xác định. Đối với SELinux, điều này biểu hiện như một vụ va chạm nhãn. Nút thiết bị chỉ có thể có một nhãn duy nhất phân giải cho bất kỳ nhãn nào được áp dụng cuối cùng. Kết quả là:

  • Quá trình cần truy cập vào các nhãn không thành công áp dụng sẽ mất quyền truy cập vào các tài nguyên.
  • Quá trình tăng quyền truy cập vào các tập tin có thể bị vỡ vì các nút thiết bị sai đã được tạo ra.

Các thuộc tính hệ thống cũng có khả năng đặt tên cho các va chạm có thể dẫn đến hành vi không xác định trên hệ thống (cũng như đối với việc gắn nhãn SELinux). Xung đột giữa nhãn nền tảng và nhà cung cấp có thể xảy ra đối với bất kỳ đối tượng nào có nhãn SELinux, bao gồm thuộc tính, dịch vụ, quy trình, tệp và ổ cắm. Để tránh những vấn đề này, hãy xác định rõ quyền sở hữu của những đối tượng này.

Ngoài xung đột nhãn, tên thuộc tính / kiểu SELinux cũng có thể xung đột. Xung đột tên thuộc tính / kiểu sẽ luôn dẫn đến lỗi trình biên dịch chính sách.

Loại / vùng chứa tên thuộc tính

SELinux không cho phép khai báo nhiều kiểu / thuộc tính giống nhau. Chính sách với các khai báo trùng lặp sẽ không thể biên dịch. Để tránh loại và tên thuộc tính va chạm, tất cả các tờ khai nhà cung cấp nên được namespaced bắt đầu với np_ .

type foo, domain; → type np_foo, domain;

Thuộc tính hệ thống và quyền sở hữu nhãn quy trình

Cách tốt nhất là tránh va chạm nhãn bằng cách sử dụng không gian tên thuộc tính. Để dễ dàng xác định thuộc tính nền tảng và tránh xung đột tên khi đổi tên hoặc thêm thuộc tính nền tảng đã xuất, hãy đảm bảo tất cả các thuộc tính của nhà cung cấp đều có tiền tố riêng:

Loại tài sản Các tiền tố được chấp nhận
có thể đọc-ghi vendor.
chỉ đọc ro.vendor.
ro.boot.
ro.hardware.
kiên trì persist.vendor.

Các nhà cung cấp có thể tiếp tục sử dụng ro.boot.* (Mà xuất phát từ cmdline kernel) và ro.hardware.* (Một đặc tính phần cứng có liên quan rõ ràng).

Tất cả các dịch vụ của nhà cung cấp trong các tập tin rc init nên có vendor. cho các dịch vụ trong tệp init rc của các phân vùng không thuộc hệ thống. Quy tắc tương tự cũng được áp dụng cho các nhãn SELinux cho các thuộc tính nhà cung cấp ( vendor_ cho các thuộc tính nhà cung cấp).

Quyền sở hữu tệp

Việc ngăn chặn xung đột cho các tệp là một thách thức vì nền tảng và chính sách của nhà cung cấp đều thường cung cấp nhãn cho tất cả các hệ thống tệp. Không giống như đặt tên kiểu, không gian tên của tệp không thực tế vì nhiều tệp trong số đó được tạo bởi hạt nhân. Để ngăn chặn những va chạm này, hãy làm theo hướng dẫn đặt tên cho hệ thống tệp trong phần này. Đối với Android 8.0, đây là các đề xuất mà không cần thực thi kỹ thuật. Trong tương lai, các đề xuất này sẽ được áp dụng bởi các nhà cung cấp thử nghiệm Suite (VTS).

Hệ thống (/ hệ thống)

Chỉ có hình ảnh hệ thống phải cung cấp nhãn cho /system thành phần thông qua file_contexts , service_contexts , vv Nếu nhãn cho /system thành phần được thêm vào /vendor chính sách, một khuôn khổ chỉ cập nhật OTA có thể không thực hiện được.

Nhà cung cấp (/ nhà cung cấp)

Chính sách AOSP SELinux đã nhãn các bộ phận của vendor phân vùng tương tác nền tảng với, mà cho phép bằng văn bản quy định SELinux cho các quá trình nền tảng để có thể nói chuyện và / hoặc các bộ phận tiếp cận của vendor phân vùng. Ví dụ:

/vendor đường Nhãn do nền tảng cung cấp Các quy trình nền tảng tùy thuộc vào nhãn
/vendor(/. * )? vendor_file Tất cả HAL khách hàng trong khuôn khổ, ueventd vv
/vendor/framework(/. * )? vendor_framework_file dex2oat , appdomain vv
/vendor/app(/. * )? vendor_app_file dex2oat , installd , idmap vv
/vendor/overlay(/. * ) vendor_overlay_file system_server , zygote , idmap vv

Kết quả là, các quy tắc cụ thể phải được tuân thủ (thực thi thông qua neverallows ) khi ghi nhãn các file bổ sung trong vendor phân vùng:

  • vendor_file phải là nhãn mặc định cho tất cả các file trong vendor phân vùng. Chính sách nền tảng yêu cầu điều này để truy cập các triển khai HAL chuyển qua.
  • Tất cả mới exec_types thêm vào trong vendor phân vùng thông qua nhà cung cấp SEPolicy phải có vendor_file_type thuộc tính. Điều này được thực thi thông qua neverallows.
  • Để tránh xung đột với nền tảng tương lai / cập nhật khung, dán nhãn file tránh khác hơn exec_types trong vendor phân vùng.
  • Tất cả phụ thuộc thư viện cho AOSP-xác định Hals quá trình tương tự phải được dán nhãn như same_process_hal_file.

Procfs (/ proc)

Tập tin trong /proc có thể được dán nhãn chỉ sử dụng genfscon nhãn. Trong Android 7.0, cả hai nền tảngnhà cung cấp chính sách sử dụng genfscon các tập tin nhãn trong procfs .

Khuyến nghị: nhãn chính sách nền tảng Chỉ /proc . Nếu vendor các quy trình cần truy cập vào tập tin trong /proc hiện được dán nhãn với nhãn mặc định ( proc ), chính sách bán hàng không nên dán nhãn rõ ràng họ và thay vào đó nên sử dụng chung proc loại thêm các quy tắc cho các tên miền nhà cung cấp. Điều này cho phép cập nhật nền tảng để chứa các giao diện hạt nhân trong tương lai tiếp xúc qua procfs và gắn nhãn cho họ một cách rõ ràng khi cần thiết.

Gỡ lỗi (/ sys / kernel / debug)

Debugfs thể được gắn nhãn trong cả file_contextsgenfscon . Trong Android 7.0 lên Android 10, cả hai nền tảng và nhà cung cấp nhãn debugfs .

Trong Android 11, debugfs không thể truy cập hoặc gắn trên các thiết bị sản xuất. Sản xuất thiết bị nên loại bỏ debugfs .

Tracefs (/ sys / kernel / debug / tracing)

Tracefs thể được gắn nhãn trong cả file_contextsgenfscon . Trong Android 7.0, chỉ có nền tảng nhãn tracefs .

Khuyến nghị: Chỉ có nền tảng thể nhãn tracefs .

Sysfs (/ sys)

File trong /sys có thể được dán nhãn sử dụng cả hai file_contextsgenfscon . Trong Android 7.0, cả hai nền tảng và nhà cung cấp sử dụng file_contextsgenfscon các tập tin nhãn trong sysfs .

Khuyến nghị: Các nền tảng có thể dán nhãn sysfs nút mà không phải là thiết bị cụ thể. Nếu không, chỉ có nhà cung cấp mới có thể gắn nhãn tệp.

tmpfs (/ dev)

Tập tin trong /dev có thể được dán nhãn trong file_contexts . Trong Android 7.0, cả tệp nhãn nền tảng và nhà cung cấp đều ở đây.

Khuyến nghị: bán hàng có thể dán nhãn chỉ tập tin trong /dev/vendor (ví dụ /dev/vendor/foo , /dev/vendor/socket/bar ).

Rootfs (/)

Tập tin trong / có thể được dán nhãn trong file_contexts . Trong Android 7.0, cả tệp nhãn nền tảng và nhà cung cấp đều ở đây.

Khuyến nghị: Chỉ có hệ thống có thể đặt tên tập tin trong / .

Dữ liệu (/ data)

Dữ liệu được dán nhãn thông qua một sự kết hợp của file_contextsseapp_contexts .

Khuyến nghị: ghi nhãn nhà cung cấp bên ngoài Disallow /data/vendor . Chỉ nền tảng có thể đặt tên các bộ phận khác của /data .

Thuộc tính tương thích

Chính sách SELinux là sự tương tác giữa các kiểu nguồn và đích cho các lớp và quyền đối tượng cụ thể. Mọi đối tượng (quy trình, tệp, v.v.) bị ảnh hưởng bởi chính sách SELinux có thể chỉ có một kiểu, nhưng kiểu đó có thể có nhiều thuộc tính.

Chính sách được viết chủ yếu dưới dạng các loại hiện có:

allow source_type target_type:target_class permission(s);

Điều này hoạt động bởi vì chính sách được viết với kiến ​​thức về tất cả các loại. Tuy nhiên, nếu chính sách nhà cung cấp và chính sách nền tảng sử dụng các loại cụ thể và nhãn của một đối tượng cụ thể chỉ thay đổi trong một trong các chính sách đó, thì chính sách còn lại có thể chứa chính sách mà trước đây đã dựa vào hoặc mất quyền truy cập. Ví dụ:

File_contexts:
/sys/A   u:object_r:sysfs:s0
Platform: allow p_domain sysfs:class perm;
Vendor: allow v_domain sysfs:class perm;

Có thể được thay đổi thành:

File_contexts:
/sys/A   u:object_r:sysfs_A:s0

Mặc dù chính sách nhà cung cấp sẽ vẫn như cũ, các v_domain sẽ mất quyền truy cập do thiếu chính sách cho cái mới sysfs_A loại.

Bằng cách xác định chính sách về mặt thuộc tính, chúng ta có thể cung cấp cho đối tượng cơ bản một loại có thuộc tính tương ứng với chính sách cho cả nền tảng và mã nhà cung cấp. Điều này có thể được thực hiện cho tất cả các loại để tạo ra hiệu quả một thuộc tính chính sách trong đó các loại bê tông không bao giờ được sử dụng. Trong thực tế, điều này là cần thiết chỉ dành cho các phần của chính sách chồng chéo giữa nền tảng và nhà cung cấp, được định nghĩa và cung cấp như chính sách công nền tảng đó được xây dựng như một phần của chính sách nhà cung cấp.

Việc xác định chính sách công dưới dạng các thuộc tính được tạo phiên bản đáp ứng hai mục tiêu về tính tương thích của chính sách:

  • Đảm bảo mã nhà cung cấp tiếp tục làm việc sau khi cập nhật nền tảng. Đạt được bằng cách thêm các thuộc tính vào các loại cụ thể cho các đối tượng tương ứng với những đối tượng mà mã nhà cung cấp dựa vào đó, duy trì quyền truy cập.
  • Có khả năng chính sách Không dùng nữa. Đạt được bằng cách phân định rõ ràng các bộ chính sách thành các thuộc tính có thể bị xóa ngay khi phiên bản mà chúng tương ứng không còn được hỗ trợ. Nền tảng có thể tiếp tục phát triển, khi biết chính sách cũ vẫn có trong chính sách của nhà cung cấp và sẽ tự động bị xóa khi / nếu nó nâng cấp.

Khả năng ghi chính sách

Để đáp ứng mục tiêu không yêu cầu kiến ​​thức về các thay đổi phiên bản cụ thể để phát triển chính sách, Android 8.0 bao gồm ánh xạ giữa các loại chính sách nền tảng-công cộng và các thuộc tính của chúng. Loại foo được ánh xạ tới thuộc tính foo_v N , nơi N là phiên bản nhắm mục tiêu. vN tương ứng với PLATFORM_SEPOLICY_VERSION biến xây dựng và có dạng MM.NN , nơi MM tương ứng với số nền tảng SDK và NN là một phiên bản nền tảng sepolicy cụ thể.

Các thuộc tính trong chính sách công khai không được tạo phiên bản, mà tồn tại dưới dạng một API trên nền tảng và chính sách của nhà cung cấp có thể xây dựng để giữ cho giao diện giữa hai phân vùng ổn định. Người viết chính sách của cả nền tảng và nhà cung cấp đều có thể tiếp tục viết chính sách như ngày nay.

Nền tảng công lập chính sách xuất khẩu như allow source_foo target_bar: class perm ; được bao gồm như một phần của chính sách nhà cung cấp. Trong biên soạn (trong đó bao gồm các phiên bản tương ứng) nó được chuyển đổi thành các chính sách mà sẽ đi đến phần nhà cung cấp của thiết bị (hiển thị trong Intermediate Language Common chuyển (CIL)):

 (allow source_foo_vN target_bar_vN (class (perm)))

Vì chính sách của nhà cung cấp không bao giờ đi trước nền tảng, nên bạn không cần quan tâm đến chính sách của các phiên bản trước. Tuy nhiên, chính sách nền tảng sẽ cần biết chính sách nhà cung cấp lùi xa đến đâu, bao gồm các thuộc tính cho các loại của nó và đặt chính sách tương ứng với các thuộc tính được phiên bản.

Chính sách khác biệt

Tự động tạo các thuộc tính bằng cách thêm _v N đến cuối của từng loại không có gì không lập bản đồ các thuộc tính với các loại trên diffs phiên bản. Android duy trì ánh xạ giữa các phiên bản cho các thuộc tính và ánh xạ các loại cho các thuộc tính đó. Điều này được thực hiện trong các tệp ánh xạ nói trên với các câu lệnh, chẳng hạn như (CIL):

(typeattributeset foo_vN (foo))

Nâng cấp nền tảng

Phần sau trình bày chi tiết các tình huống nâng cấp nền tảng.

Cùng loại

Trường hợp này xảy ra khi một đối tượng không thay đổi nhãn trong các phiên bản chính sách. Đây là giống nhau cho nguồn và đích chủng loại và có thể được nhìn thấy với /dev/binder , được dán nhãn binder_device trên tất cả các phiên. Nó được thể hiện trong chính sách được chuyển đổi dưới dạng:

binder_device_v1 … binder_device_vN

Khi nâng cấp từ v1v2 , chính sách nền tảng phải bao gồm:

type binder_device; -> (type binder_device) (in CIL)

Trong tệp ánh xạ v1 (CIL):

(typeattributeset binder_device_v1 (binder_device))

Trong tệp ánh xạ v2 (CIL):

(typeattributeset binder_device_v2 (binder_device))

Trong chính sách nhà cung cấp v1 (CIL):

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

Trong chính sách nhà cung cấp v2 (CIL):

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
Các loại mới

Trường hợp này xảy ra khi nền tảng đã thêm một loại mới, điều này có thể xảy ra khi thêm các tính năng mới hoặc trong quá trình tăng cường chính sách.

  • Tính năng mới. Khi loại đang gắn nhãn một đối tượng trước đó không tồn tại (chẳng hạn như quy trình dịch vụ mới), mã nhà cung cấp trước đó không tương tác trực tiếp với nó nên không tồn tại chính sách tương ứng. Thuộc tính mới tương ứng với loại không có thuộc tính trong phiên bản trước và do đó sẽ không cần mục nhập trong tệp ánh xạ nhắm mục tiêu phiên bản đó.
  • Chính sách cứng. Khi các loại đại diện cứng chính sách, các loại thuộc tính mới phải liên kết lại với một chuỗi các thuộc tính tương ứng với trước đó (tương tự như ví dụ trước thay đổi /sys/A từ sysfs để sysfs_A ). Đang cung cấp dựa trên một quy tắc cho phép truy cập đến sysfs , và cần phải bao gồm quy tắc đó như một thuộc tính của kiểu mới.

Khi nâng cấp từ v1v2 , chính sách nền tảng phải bao gồm:

type sysfs_A; -> (type sysfs_A) (in CIL)
type sysfs; (type sysfs) (in CIL)

Trong tệp ánh xạ v1 (CIL):

(typeattributeset sysfs_v1 (sysfs sysfs_A))

Trong tệp ánh xạ v2 (CIL):

(typeattributeset sysfs_v2 (sysfs))
(typeattributeset sysfs_A_v2 (sysfs_A))

Trong chính sách nhà cung cấp v1 (CIL):

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Trong chính sách nhà cung cấp v2 (CIL):

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)
Đã loại bỏ các loại

Trường hợp (hiếm) này xảy ra khi một loại bị xóa, có thể xảy ra khi đối tượng cơ bản:

  • Vẫn còn nhưng có một nhãn khác.
  • Bị loại bỏ bởi nền tảng.

Trong quá trình nới lỏng chính sách, một loại sẽ bị xóa và đối tượng được gắn nhãn loại đó sẽ được cấp một nhãn khác, đã tồn tại. Điều này thể hiện sự hợp nhất của các ánh xạ thuộc tính: Mã nhà cung cấp vẫn phải có thể truy cập đối tượng cơ bản theo thuộc tính mà nó đã sử dụng để sở hữu, nhưng phần còn lại của hệ thống hiện phải có thể truy cập đối tượng đó bằng thuộc tính mới của nó.

Nếu thuộc tính mà nó đã được chuyển sang là thuộc tính mới, thì việc gắn nhãn lại giống như trong trường hợp kiểu mới, ngoại trừ khi một nhãn hiện có được sử dụng, việc bổ sung thuộc tính cũ kiểu mới sẽ khiến các đối tượng khác cũng được gắn nhãn với kiểu này để có thể truy cập mới. Về cơ bản, đây là những gì được thực hiện bởi nền tảng và được coi là sự đánh đổi có thể chấp nhận được để duy trì khả năng tương thích.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Phiên bản ví dụ 1: Các kiểu thu gọn (xóa sysfs_A)

Khi nâng cấp từ v1v2 , chính sách nền tảng phải bao gồm:

type sysfs; (type sysfs) (in CIL)

Trong tệp ánh xạ v1 (CIL):

(typeattributeset sysfs_v1 (sysfs))
(type sysfs_A) # in case vendors used the sysfs_A label on objects
(typeattributeset sysfs_A_v1 (sysfs sysfs_A))

Trong tệp ánh xạ v2 (CIL):

(typeattributeset sysfs_v2 (sysfs))

Trong chính sách nhà cung cấp v1 (CIL):

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Trong chính sách nhà cung cấp v2 (CIL):

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Phiên bản ví dụ 2: Loại bỏ hoàn toàn (loại foo)

Khi nâng cấp từ v1v2 , chính sách nền tảng phải bao gồm:

# nothing - we got rid of the type

Trong tệp ánh xạ v1 (CIL):

(type foo) #needed in case vendors used the foo label on objects
(typeattributeset foo_v1 (foo))

Trong tệp ánh xạ v2 (CIL):

# nothing - get rid of it

Trong chính sách nhà cung cấp v1 (CIL):

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

Trong chính sách nhà cung cấp v2 (CIL):

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
Lớp / quyền mới

Trường hợp này xảy ra khi nâng cấp nền tảng giới thiệu các thành phần chính sách mới không tồn tại trong các phiên bản trước. Ví dụ, khi Android thêm servicemanager quản lý đối tượng đã tạo ra tiện ích, tìm kiếm, và cho phép danh sách, daemon nhà cung cấp muốn đăng ký với servicemanager quyền cần thiết mà không có sẵn. Trong Android 8.0, chỉ chính sách nền tảng mới có thể thêm các lớp và quyền mới.

Để cho phép tất cả các miền có thể đã được tạo hoặc mở rộng bởi chính sách của nhà cung cấp để sử dụng lớp mới mà không bị cản trở, chính sách nền tảng cần bao gồm một quy tắc tương tự như:

allow {domain -coredomain} *:new_class perm;

Điều này thậm chí có thể yêu cầu chính sách cho phép truy cập cho tất cả các loại giao diện (chính sách công khai), để đảm bảo hình ảnh của nhà cung cấp có được quyền truy cập. Nếu điều này dẫn đến chính sách bảo mật không được chấp nhận (vì nó có thể có với các thay đổi của người quản lý dịch vụ), thì có thể buộc phải nâng cấp nhà cung cấp.

Đã xóa lớp / quyền

Kịch bản này xảy ra khi một người quản lý đối tượng được lấy ra (ví dụ như ZygoteConnection quản lý đối tượng) và không nên gây ra vấn đề. Lớp quản lý đối tượng và quyền có thể vẫn được xác định trong chính sách cho đến khi phiên bản của nhà cung cấp không còn sử dụng nó nữa. Điều này được thực hiện bằng cách thêm các định nghĩa vào tệp ánh xạ tương ứng.

Tùy chỉnh của nhà cung cấp cho các loại mới / được gắn nhãn lại

Các loại nhà cung cấp mới là cốt lõi của việc phát triển chính sách nhà cung cấp vì chúng cần thiết để mô tả các quy trình, mã nhị phân, thiết bị, hệ thống con và dữ liệu được lưu trữ mới. Do đó, bắt buộc phải cho phép tạo các kiểu do nhà cung cấp xác định.

Vì chính sách nhà cung cấp luôn là chính sách cũ nhất trên thiết bị, nên không cần phải tự động chuyển đổi tất cả các loại nhà cung cấp thành các thuộc tính trong chính sách. Nền tảng không dựa trên bất kỳ thứ gì được dán nhãn trong chính sách của nhà cung cấp bởi vì nền tảng không có kiến ​​thức về nó; Tuy nhiên, nền tảng này sẽ cung cấp các thuộc tính và các loại công nó sử dụng để tương tác với các đối tượng được dán nhãn với các loại (ví dụ như domain , sysfs_type , vv). Đối với nền tảng để tiếp tục tương tác một cách chính xác với các đối tượng, các thuộc tính và các loại phải được áp dụng một cách thích hợp và các quy tắc cụ thể cần phải được bổ sung vào các lĩnh vực tùy biến (như init ).

Các thay đổi về thuộc tính cho Android 9

Thiết bị nâng cấp lên Android 9 có thể sử dụng các thuộc tính sau, nhưng thiết bị khởi chạy với Android 9 thì không.

Thuộc tính người vi phạm

Android 9 bao gồm các thuộc tính liên quan đến miền sau:

  • data_between_core_and_vendor_violators . Thuộc tính cho tất cả các lĩnh vực vi phạm các yêu cầu của không chia sẻ file theo đường dẫn giữa vendorcoredomains . Các quy trình nền tảng và nhà cung cấp không nên sử dụng tệp trên đĩa để giao tiếp (ABI không ổn định). Sự giới thiệu:
    • Đang bán hàng nên sử dụng /data/vendor .
    • Hệ thống không nên sử dụng /data/vendor .
  • system_executes_vendor_violators . Thuộc tính cho tất cả các lĩnh vực hệ thống (trừ initshell domains ) vi phạm các yêu cầu của việc không thực thi mã nhị phân nhà cung cấp. Thực thi mã nhị phân của nhà cung cấp có API không ổn định. Nền tảng không nên thực thi mã nhị phân của nhà cung cấp trực tiếp. Sự giới thiệu:
    • Các nền tảng phụ thuộc như vậy vào các tệp nhị phân của nhà cung cấp phải nằm sau HIDL HAL.

      HOẶC

    • coredomains rằng cần truy cập vào mã nhị phân nhà cung cấp nên được chuyển đến phân vùng nhà cung cấp và do đó, dừng lại là coredomain .

Thuộc tính không đáng tin cậy

Các ứng dụng không đáng tin cậy lưu trữ mã tùy ý sẽ không có quyền truy cập vào các dịch vụ HwBinder, ngoại trừ những ứng dụng được coi là đủ an toàn để truy cập từ các ứng dụng đó (xem các dịch vụ an toàn bên dưới). Hai lý do chính cho điều này là:

  1. Máy chủ HwBinder không thực hiện xác thực máy khách vì HIDL hiện không tiết lộ thông tin UID của người gọi. Ngay cả khi HIDL đã tiết lộ dữ liệu như vậy, nhiều dịch vụ HwBinder hoặc hoạt động ở cấp thấp hơn ứng dụng (chẳng hạn như HAL) hoặc không được dựa vào nhận dạng ứng dụng để ủy quyền. Do đó, để an toàn, giả định mặc định là mọi dịch vụ của HwBinder đều coi tất cả các khách hàng của mình được ủy quyền như nhau để thực hiện các hoạt động do dịch vụ cung cấp.
  2. Máy chủ HAL (một tập hợp con của các dịch vụ HwBinder) chứa mã với tốc độ tỷ lệ cao hơn về các vấn đề an ninh hơn so với system/core linh kiện và được tiếp cận với các lớp dưới của ngăn xếp (tất cả các con đường xuống đến phần cứng) do đó tăng cơ hội cho bỏ qua các mô hình bảo mật của Android .

Dịch vụ an toàn

Các dịch vụ an toàn bao gồm:

  • same_process_hwservice . Các dịch vụ này (theo định nghĩa) chạy trong tiến trình của máy khách và do đó có cùng quyền truy cập với miền máy khách mà quá trình chạy.
  • coredomain_hwservice . Các dịch vụ này không gây ra rủi ro liên quan đến lý do số 2.
  • hal_configstore_ISurfaceFlingerConfigs . Dịch vụ này được thiết kế đặc biệt để sử dụng bởi bất kỳ miền nào.
  • hal_graphics_allocator_hwservice . Các hoạt động này cũng được cung cấp bởi surfaceflinger dịch vụ Binder, mà các ứng dụng được phép truy cập.
  • hal_omx_hwservice . Đây là một phiên bản HwBinder của mediacodec dịch vụ Binder, mà các ứng dụng được phép truy cập.
  • hal_codec2_hwservice . Đây là một phiên bản mới hơn của hal_omx_hwservice .

Các thuộc tính có thể sử dụng

Tất cả hwservices không được coi là an toàn có thuộc tính untrusted_app_visible_hwservice . Các máy chủ HAL tương ứng có thuộc tính untrusted_app_visible_halserver . Thiết bị tung ra với Android 9 không sử dụng hoặc untrusted thuộc tính.

Sự giới thiệu:

  • Thay vào đó, các ứng dụng không đáng tin cậy sẽ nói chuyện với một dịch vụ hệ thống nói chuyện với HIDL HAL của nhà cung cấp. Ví dụ, ứng dụng có thể nói chuyện với binderservicedomain , sau đó mediaserver (mà là một binderservicedomain ) trong cuộc đàm phán chuyển sang các hal_graphics_allocator .

    HOẶC

  • Ứng dụng cần truy cập trực tiếp đến vendor Hals nên có nhà cung cấp xác định miền sepolicy riêng của họ.

Kiểm tra thuộc tính tệp

Android 9 bao gồm các bài kiểm tra thời gian xây dựng để đảm bảo tất cả các file tại các địa điểm cụ thể có các thuộc tính thích hợp (ví dụ như, tất cả các file trong sysfs có cần sysfs_type thuộc tính).

Chính sách nền tảng-công khai

Chính sách nền tảng-công khai là cốt lõi của việc tuân thủ mô hình kiến ​​trúc Android 8.0 mà không chỉ đơn giản là duy trì sự kết hợp của các chính sách nền tảng từ v1 và v2. Các nhà cung cấp được tiếp xúc với một tập hợp con của chính sách nền tảng đó có chứa các loại sử dụng được và các thuộc tính và quy định về các loại và các thuộc tính mà sau đó trở thành một phần của chính sách nhà cung cấp (ví dụ vendor_sepolicy.cil ).

Chủng loại và quy tắc được tự động dịch trong chính sách nhà cung cấp được tạo ra vào attribute_v N sao cho tất cả các loại nền tảng cung cấp đang là phiên bản thuộc tính (tuy nhiên các thuộc tính không được phiên bản). Nền tảng chịu trách nhiệm ánh xạ các loại cụ thể mà nó cung cấp thành các thuộc tính thích hợp để đảm bảo rằng chính sách của nhà cung cấp tiếp tục hoạt động và các quy tắc được cung cấp cho một phiên bản cụ thể được bao gồm. Sự kết hợp giữa chính sách nền tảng-công cộng và chính sách nhà cung cấp đáp ứng mục tiêu của mô hình kiến ​​trúc Android 8.0 là cho phép xây dựng nền tảng và nhà cung cấp độc lập.

Ánh xạ tới các chuỗi thuộc tính

Khi sử dụng các thuộc tính để ánh xạ đến các phiên bản chính sách, một loại ánh xạ tới một thuộc tính hoặc nhiều thuộc tính, đảm bảo các đối tượng được gắn nhãn loại có thể truy cập được thông qua các thuộc tính tương ứng với loại trước đó của chúng.

Duy trì mục tiêu để ẩn thông tin phiên bản khỏi người viết chính sách có nghĩa là tự động tạo các thuộc tính được tạo phiên bản và gán chúng cho các loại thích hợp. Trong trường hợp thông thường của các loại tĩnh, đây là đơn giản: type_foo bản đồ để type_foo_v1 .

Đối với một đối tượng thay đổi nhãn như sysfssysfs_A hoặc mediaserveraudioserver , tạo lập bản đồ này là không tầm thường (và được mô tả trong các ví dụ trên). Người duy trì chính sách nền tảng phải xác định cách tạo ánh xạ tại các điểm chuyển tiếp cho các đối tượng, điều này đòi hỏi phải hiểu mối quan hệ giữa các đối tượng và nhãn được gán của chúng và xác định khi nào điều này xảy ra. Để có khả năng tương thích ngược, sự phức tạp này cần được quản lý ở phía nền tảng, đây là phân vùng duy nhất có thể nâng cấp.

Phiên bản nâng cấp

Để đơn giản, nền tảng Android phát hành một phiên bản riêng biệt khi một nhánh phát hành mới bị cắt. Như đã trình bày ở trên, số phiên bản được chứa trong PLATFORM_SEPOLICY_VERSION và có dạng MM.nn , nơi MM tương ứng với giá trị SDK và nn là một giá trị riêng duy trì trong /platform/system/sepolicy. Ví dụ, 19.0 cho Kitkat, 21.0 cho Lollipop, 22.0 cho Lollipop-MR1 23.0 cho Marshmallow, 24.0 cho Nougat, 25.0 cho Nougat-MR1, 26.0 cho Oreo, 27.0 cho Oreo-MR1, và 28.0 cho Android 9. Uprevs không luôn luôn là số nguyên. Ví dụ, nếu một vết sưng MR đến một phiên bản đòi hỏi một sự thay đổi không phù hợp trong system/sepolicy/public nhưng không phải là một vết sưng API, sau đó phiên bản sepolicy có thể là: vN.1 . Phiên bản hiện tại một chi nhánh phát triển là một bao giờ-to-be-dùng-in-vận chuyển-thiết bị 10000.0 .

Android có thể không dùng phiên bản cũ nhất khi nâng cấp. Để biết thông tin đầu vào về thời điểm không dùng phiên bản, Android có thể thu thập số lượng thiết bị có chính sách của nhà cung cấp đang chạy phiên bản Android đó và vẫn nhận được các bản cập nhật nền tảng lớn. Nếu số lượng nhỏ hơn một ngưỡng nhất định, phiên bản đó không được dùng nữa.

Tác động hiệu suất của nhiều thuộc tính

Như đã trình bày trong https://github.com/SELinuxProject/cil/issues/9 , một số lượng lớn các thuộc tính được gán cho một kết quả gõ vào vấn đề hiệu suất trong trường hợp của một cache chính sách.

Điều này đã được khẳng định là một vấn đề trong Android, vì vậy những thay đổi đã được thực hiện để Android 8.0 để loại bỏ các thuộc tính bổ sung vào chính sách bởi trình biên dịch chính sách, cũng như để loại bỏ các thuộc tính không sử dụng. Những thay đổi này đã giải quyết các hồi quy về hiệu suất.

Gắn nhãn ngữ cảnh SELinux

Để hỗ trợ sự phân biệt giữa nền tảng và nhà cung cấp riêng biệt, hệ thống xây dựng các tệp ngữ cảnh SELinux khác nhau để giữ chúng riêng biệt.

Bối cảnh tệp

Android 8.0 giới thiệu những thay đổi sau đây cho file_contexts :

  • Để tránh thêm overhead biên soạn trên điện thoại trong khi khởi động, file_contexts chấm dứt tồn tại dưới dạng nhị phân. Thay vào đó, họ có thể được đọc, thường xuyên tập tin văn bản biểu hiện như {property, service}_contexts (như họ đã sẵn 7.0).
  • Các file_contexts được phân chia giữa hai tập tin:
    • plat_file_contexts
      • Nền tảng Android file_context mà không có nhãn thiết bị cụ thể, ngoại trừ cho các bộ phận ghi nhãn /vendor phân vùng đó phải được dán nhãn chính xác để đảm bảo hoạt động đúng đắn của các tập tin sepolicy.
      • Phải nằm trong system phân vùng ở /system/etc/selinux/plat_file_contexts trên thiết bị và được nạp bởi init lúc bắt đầu cùng với các nhà cung cấp file_context .
    • vendor_file_contexts
      • Thiết bị cụ thể file_context xây dựng bằng cách kết hợp file_contexts tìm thấy trong thư mục trỏ đến bởi BOARD_SEPOLICY_DIRS trong của thiết bị Boardconfig.mk tập tin.
      • Phải được lắp đặt tại /vendor/etc/selinux/vendor_file_contexts trong vendor phân vùng và được nạp bởi init lúc bắt đầu cùng với nền tảng file_context .

Bối cảnh tài sản

Trong Android 8.0, các property_contexts là chia rẽ giữa hai tập tin:

  • plat_property_contexts
    • Nền tảng Android property_context mà không có nhãn thiết bị cụ thể.
    • Phải nằm trong system phân vùng ở /system/etc/selinux/plat_property_contexts và được nạp bởi init lúc bắt đầu cùng với các nhà cung cấp property_contexts .
  • vendor_property_contexts
    • Thiết bị cụ thể property_context xây dựng bằng cách kết hợp property_contexts tìm thấy trong thư mục trỏ đến bởi BOARD_SEPOLICY_DIRS trong thiết bị của Boardconfig.mk tập tin.
    • Phải cư trú tại vendor phân vùng ở /vendor/etc/selinux/vendor_property_contexts và được nạp bởi init lúc bắt đầu cùng với nền tảng property_context

Bối cảnh dịch vụ

Trong Android 8.0, các service_contexts là chia rẽ giữa các tập tin sau đây:

  • plat_service_contexts
    • Android nền tảng cụ thể service_context cho servicemanager . Các service_context không có nhãn thiết bị cụ thể.
    • Phải nằm trong system phân vùng ở /system/etc/selinux/plat_service_contexts và được nạp bởi servicemanager lúc bắt đầu cùng với các nhà cung cấp service_contexts .
  • vendor_service_contexts
    • Thiết bị cụ thể service_context xây dựng bằng cách kết hợp service_contexts tìm thấy trong thư mục trỏ đến bởi BOARD_SEPOLICY_DIRS trong của thiết bị Boardconfig.mk tập tin.
    • Phải cư trú tại vendor phân vùng ở /vendor/etc/selinux/vendor_service_contexts và được nạp bởi servicemanager lúc bắt đầu cùng với nền tảng service_contexts .
    • Mặc dù servicemanager vẻ cho tập tin này vào lúc khởi động, đối với một hoàn toàn tuân thủ TREBLE thiết bị, vendor_service_contexts PHẢI KHÔNG tồn tại. Điều này là do tất cả các tương tác giữa vendorsystem các quy trình PHẢI đi qua hwservicemanager / hwbinder .
  • plat_hwservice_contexts
    • Nền tảng Android hwservice_context cho hwservicemanager mà không có nhãn thiết bị cụ thể.
    • Phải nằm trong system phân vùng ở /system/etc/selinux/plat_hwservice_contexts và được nạp bởi hwservicemanager lúc bắt đầu cùng với vendor_hwservice_contexts .
  • vendor_hwservice_contexts
    • Thiết bị cụ thể hwservice_context xây dựng bằng cách kết hợp hwservice_contexts tìm thấy trong thư mục trỏ đến bởi BOARD_SEPOLICY_DIRS trong của thiết bị Boardconfig.mk tập tin.
    • Phải cư trú tại vendor phân vùng ở /vendor/etc/selinux/vendor_hwservice_contexts và được nạp bởi hwservicemanager lúc bắt đầu cùng với plat_service_contexts .
  • vndservice_contexts
    • Thiết bị cụ thể service_context cho vndservicemanager xây dựng bằng cách kết hợp vndservice_contexts tìm thấy trong thư mục trỏ đến bởi BOARD_SEPOLICY_DIRS trong của thiết bị Boardconfig.mk .
    • Tập tin này phải cư trú tại vendor phân vùng ở /vendor/etc/selinux/vndservice_contexts và được nạp bởi vndservicemanager lúc bắt đầu.

Bối cảnh Seapp

Trong Android 8.0, các seapp_contexts là chia rẽ giữa hai tập tin:

  • plat_seapp_contexts
    • Nền tảng Android seapp_context mà không có thay đổi thiết bị cụ thể.
    • Phải nằm trong system phân vùng ở /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • Mở rộng điện thoại cụ thể để nền tảng seapp_context xây dựng bằng cách kết hợp seapp_contexts tìm thấy trong thư mục trỏ đến bởi BOARD_SEPOLICY_DIRS trong của thiết bị Boardconfig.mk tập tin.
    • Phải cư trú tại vendor phân vùng ở /vendor/etc/selinux/vendor_seapp_contexts .

Quyền MAC

Trong Android 8.0, các mac_permissions.xml là chia rẽ giữa hai tập tin:

  • nền tảng mac_permissions.xml
    • Nền tảng Android mac_permissions.xml mà không có thay đổi thiết bị cụ thể.
    • Phải nằm trong system phân vùng ở /system/etc/selinux/.
  • Non-Platform mac_permissions.xml
    • Mở rộng điện thoại cụ thể để nền tảng mac_permissions.xml xây dựng từ mac_permissions.xml tìm thấy trong thư mục trỏ đến bởi BOARD_SEPOLICY_DIRS trong của thiết bị Boardconfig.mk tập tin.
    • Phải cư trú tại vendor phân vùng ở /vendor/etc/selinux/.