کنترل دسترسی اختیاری (DAC)

با مجموعه‌ها، منظم بمانید ذخیره و دسته‌بندی محتوا براساس اولویت‌های شما.

اشیاء و سرویس‌های فایل سیستمی که به ساخت اضافه می‌شوند اغلب به شناسه‌های جداگانه و منحصربه‌فرد نیاز دارند که به نام Android ID (AIDs) شناخته می‌شوند. در حال حاضر، بسیاری از منابع مانند فایل‌ها و سرویس‌ها از ایدزهای اصلی (تعریف شده توسط اندروید) غیر ضروری استفاده می‌کنند. در بسیاری از موارد می توانید به جای آن از ایدزهای OEM (OEM-defined) استفاده کنید.

نسخه‌های قبلی Android (Android 7.x و پایین‌تر) مکانیسم AIDs را با استفاده از یک فایل android_filesystem_config.h مخصوص دستگاه برای مشخص کردن قابلیت‌های سیستم فایل و/یا AID‌های OEM سفارشی گسترش دادند. با این حال، این سیستم غیرمعمول بود، زیرا از استفاده از نام‌های خوب برای AID‌های OEM پشتیبانی نمی‌کرد، و شما را ملزم می‌کرد که عدد خام را برای فیلدهای کاربر و گروه بدون هیچ راهی برای مرتبط کردن نام دوستانه با AID عددی مشخص کنید.

نسخه های جدیدتر اندروید (اندروید 8.0 و بالاتر) از روش جدیدی برای گسترش قابلیت های سیستم فایل پشتیبانی می کنند. این روش جدید از موارد زیر پشتیبانی می کند:

  • چندین مکان منبع برای فایل های پیکربندی (پیکربندی های ساخت قابل توسعه را فعال می کند).
  • بررسی سلامت عقل در زمان ساخت مقادیر AID OEM.
  • تولید یک هدر سفارشی OEM AID که می تواند در صورت نیاز در فایل های منبع استفاده شود.
  • ارتباط یک نام دوستانه با ارزش واقعی OEM AID. از آرگومان های رشته ای غیر عددی برای کاربر و گروه پشتیبانی می کند، یعنی "foo" به جای "2901".

بهبودهای اضافی شامل حذف آرایه android_ids[] از system/core/libcutils/include/private/android_filesystem_config.h است. این آرایه اکنون در Bionic به‌عنوان یک آرایه کاملاً خصوصی تولید شده، با دسترسی‌هایی از طریق getpwnam() و getgrnam() وجود دارد. (این اثر جانبی تولید باینری های پایدار را دارد زیرا AID های اصلی اصلاح می شوند.) برای ابزار و فایل README با جزئیات بیشتر، به build/make/tools/fs_config کنید.

افزودن شناسه اندروید (AIDS)

Android 8.0 آرایه android_ids[] از پروژه منبع باز Android (AOSP) حذف کرد. همه نام‌های سازگار با AID در عوض از فایل هدر system/core/libcutils/include/private/android_filesystem_config.h هنگام تولید آرایه Bionic android_ids[] تولید می‌شوند. هر define مطابق با AID_* توسط ابزار انتخاب می شود و * به نام کوچک تبدیل می شود.

به عنوان مثال، در private/android_filesystem_config.h :

#define AID_SYSTEM 1000

تبدیل می شود:

  • نام دوستانه: سیستم
  • یوید: 1000
  • gid: 1000

برای افزودن یک AID هسته AOSP جدید، کافی است #define را به فایل هدر android_filesystem_config.h اضافه کنید. AID در زمان ساخت تولید می شود و در دسترس رابط هایی قرار می گیرد که از آرگومان های کاربر و گروه استفاده می کنند. ابزار تایید می کند که AID جدید در محدوده APP یا OEM نیست. همچنین به تغییرات آن محدوده‌ها احترام می‌گذارد و باید به‌طور خودکار در تغییرات یا محدوده‌های جدید OEM رزرو شده مجدداً پیکربندی شود.

پیکربندی ایدز

برای فعال کردن مکانیسم AIDs جدید، TARGET_FS_CONFIG_GEN را در فایل BoardConfig.mk کنید. این متغیر فهرستی از فایل های پیکربندی را در خود جای می دهد که به شما امکان می دهد در صورت نیاز فایل ها را اضافه کنید.

طبق قرارداد، فایل های پیکربندی از نام config.fs استفاده می کنند، اما در عمل می توانید از هر نامی استفاده کنید. فایل‌های config.fs در قالب Python ConfigParser ini هستند و شامل یک بخش caps (برای پیکربندی قابلیت‌های سیستم فایل) و یک بخش AIDs (برای پیکربندی OEM AIDs) هستند.

پیکربندی بخش caps

بخش caps از تنظیم قابلیت های سیستم فایل بر روی اشیاء سیستم فایل در ساخت پشتیبانی می کند (خود سیستم فایل نیز باید از این قابلیت پشتیبانی کند).

از آنجایی که اجرای یک سرویس پایدار به‌عنوان روت در اندروید باعث خرابی مجموعه تست سازگاری (CTS) می‌شود، الزامات قبلی برای حفظ یک قابلیت در حین اجرای یک فرآیند یا سرویس مستلزم راه‌اندازی قابلیت‌ها و سپس استفاده از setuid / setgid به یک AID مناسب برای اجرا بود. با استفاده از caps، می‌توانید این الزامات را نادیده بگیرید و از هسته بخواهید این کار را برای شما انجام دهد. هنگامی که کنترل به main() داده می شود، فرآیند شما از قبل قابلیت های مورد نیاز خود را دارد، بنابراین سرویس شما می تواند از یک کاربر و گروه غیر ریشه استفاده کند (این روش ترجیحی برای شروع سرویس های ممتاز است).

بخش caps از نحو زیر استفاده می کند:

بخش مقدار تعریف
[path] مسیر فایل سیستم برای پیکربندی مسیری که به / ختم می شود یک dir در نظر گرفته می شود، در غیر این صورت یک فایل است.

تعیین چندین بخش با [path] یکسان در فایل های مختلف یک خطا است. در نسخه های پایتون <= 3.2، همان فایل ممکن است شامل بخش هایی باشد که بخش قبلی را لغو می کند. در پایتون 3.2 روی حالت سخت تنظیم شده است.
mode حالت فایل هشتگانه حالت فایل هشتگانه معتبر حداقل 3 رقمی. اگر 3 مشخص شده باشد، پیشوند آن 0 است، حالت else همانطور که هست استفاده می شود.
user AID_<کاربر> یا C برای یک AID معتبر define یا نام دوستانه (مثلا AID_RADIO و radio هر دو قابل قبول هستند). برای تعریف یک AID سفارشی، به پیکربندی بخش AID مراجعه کنید.
group AID_<گروه> همان کاربر.
caps کلاه لبه دار* نامی که در bionic/libc/kernel/uapi/linux/capability.h بدون CAP_ اصلی اعلام شده است. مورد مختلط مجاز است. کلاه ها همچنین می توانند خام باشند:
  • باینری (0b0101)
  • هشتی (0455)
  • int (42)
  • هگز (0xFF)
چندین سرپوش را با استفاده از فضاهای خالی جدا کنید.

برای مثال استفاده، استفاده از قابلیت های سیستم فایل را ببینید.

پیکربندی بخش AID

بخش AID شامل AID های OEM است و از نحو زیر استفاده می کند:

بخش مقدار تعریف
[AID_<name>] <name> می تواند شامل کاراکترهایی با حروف بزرگ، اعداد و زیرخط باشد. نسخه کوچک به عنوان نام دوستانه استفاده می شود. فایل هدر ایجاد شده برای گنجاندن کد از AID_<name> دقیق استفاده می کند.

تعیین چندین بخش با AID_<name> یکسان (بدون حساس به حروف کوچک با محدودیت‌های مشابه [path] ) یک خطا است.

<name> باید با نام پارتیشن شروع شود تا اطمینان حاصل شود که با منابع مختلف تضاد ندارد.
value <تعداد> یک رشته اعداد معتبر به سبک C (هگز، اکتال، باینری و اعشاری).

این یک خطا است که چندین بخش را با گزینه مقدار یکسان مشخص کنید.

گزینه های مقدار باید در محدوده مربوط به پارتیشن مورد استفاده در <name> مشخص شوند. لیست پارتیشن های معتبر و محدوده های مربوط به آنها در system/core/libcutils/include/private/android_filesystem_config.h تعریف شده است. گزینه ها عبارتند از:
  • پارتیشن فروشنده
    • AID_OEM_RESERVED_START(2900) - AID_OEM_RESERVED_END(2999)
    • AID_OEM_RESERVED_2_START(5000) - AID_OEM_RESERVED_2_END(5999)
  • پارتیشن سیستم
    • AID_SYSTEM_RESERVED_START(6000) - AID_SYSTEM_RESERVED_END(6499)
  • پارتیشن ODM
    • AID_ODM_RESERVED_START(6500) - AID_ODM_RESERVED_END(6999)
  • پارتیشن محصول
    • AID_PRODUCT_RESERVED_START(7000) - AID_PRODUCT_RESERVED_END(7499)
  • پارتیشن System_ext
    • AID_SYSTEM_EXT_RESERVED_START(7500) - AID_SYSTEM_EXT_RESERVED_END(7999)

برای مثال‌های استفاده، به تعریف نام‌های OEM AID و استفاده از OEM AIDs مراجعه کنید.

نمونه های استفاده

مثال‌های زیر نحوه تعریف و استفاده از OEM AID و نحوه فعال کردن قابلیت‌های سیستم فایل را توضیح می‌دهند. نام‌های OEM AID ( [AID_ name ] ) باید با نام پارتیشنی مانند " vendor_ " شروع شوند تا اطمینان حاصل شود که با نام‌های AOSP آینده یا سایر پارتیشن‌ها تضاد ندارند.

تعریف نام های OEM AID

برای تعریف یک OEM AID، یک فایل config.fs ایجاد کنید و مقدار AID را تنظیم کنید. به عنوان مثال، در device/x/y/config.fs موارد زیر را تنظیم کنید:

[AID_VENDOR_FOO]
value: 2900

پس از ایجاد فایل، متغیر TARGET_FS_CONFIG_GEN را تنظیم کرده و در BoardConfig.mk به آن اشاره کنید. به عنوان مثال، در device/x/y/BoardConfig.mk موارد زیر را تنظیم کنید:

TARGET_FS_CONFIG_GEN += device/x/y/config.fs

AID سفارشی شما اکنون می تواند توسط سیستم به طور کلی در یک ساخت جدید مصرف شود.

استفاده از OEM AIDs

برای استفاده از OEM AID، در کد C خود، oemaids_headers را در Makefile مرتبط خود وارد کنید و #include "generated_oem_aid.h" را اضافه کنید، سپس شروع به استفاده از شناسه های اعلام شده کنید. به عنوان مثال، در my_file.c ، موارد زیر را اضافه کنید:

#include "generated_oem_aid.h"
…

If (ipc->uid == AID_VENDOR_FOO) {
  // Do something
...

در فایل Android.bp مرتبط خود، موارد زیر را اضافه کنید:

header_libs: ["oemaids_headers"],

اگر از فایل Android.mk استفاده می کنید، موارد زیر را اضافه کنید:

LOCAL_HEADER_LIBRARIES := oemaids_headers

استفاده از اسامی دوستانه

در اندروید 9، می‌توانید از نام دوستانه برای هر رابطی که از نام‌های AID پشتیبانی می‌کند استفاده کنید. مثلا:

  • در یک دستور chown در some/init.rc :
    chown vendor_foo /vendor/some/vendor_foo/file
    
  • در service در some/init.rc :
    service vendor_foo /vendor/bin/foo_service
        user vendor_foo
        group vendor_foo
    

از آنجا که نگاشت داخلی از نام دوستانه به uid توسط /vendor/etc/passwd و /vendor/etc/group انجام می شود، پارتیشن فروشنده باید نصب شود.

تداعی نام های دوستانه

اندروید 9 شامل پشتیبانی برای مرتبط کردن یک نام دوستانه با مقدار واقعی OEM AID است. می‌توانید از آرگومان‌های رشته‌ای غیر عددی برای کاربر و گروه استفاده کنید، یعنی به جای «2901» از « vendor_ foo».

تبدیل از AID به نام های دوستانه

برای OEM AIDs ، Android 8.x به استفاده از oem_#### با getpwnam و توابع مشابه، و همچنین در مکان‌هایی که جستجوها را از طریق getpwnam (مانند اسکریپت‌های init ) نیاز دارد. در اندروید 9 می‌توانید از دوستان getpwnam و getgrnam در Bionic برای تبدیل از شناسه‌های اندروید (AIDs) به نام‌های دوستانه و بالعکس استفاده کنید.

استفاده از قابلیت های سیستم فایل

برای فعال کردن قابلیت‌های سیستم فایل، یک بخش caps در فایل config.fs ایجاد کنید. به عنوان مثال، در device/x/y/config.fs ، بخش زیر را اضافه کنید:

[system/bin/foo_service]
mode: 0555
user: AID_VENDOR_FOO
group: AID_SYSTEM
caps: SYS_ADMIN | SYS_NICE

پس از ایجاد فایل، TARGET_FS_CONFIG_GEN را تنظیم کنید تا به آن فایل در BoardConfig.mk کند. به عنوان مثال، در device/x/y/BoardConfig.mk موارد زیر را تنظیم کنید:

TARGET_FS_CONFIG_GEN += device/x/y/config.fs

وقتی سرویس vendor_ foo اجرا می‌شود، با قابلیت‌های CAP_SYS_ADMIN و CAP_SYS_NICE بدون تماس‌های setuid و setgid . علاوه بر این، خط مشی SELinux سرویس vendor_ foo دیگر نیازی به قابلیت setuid و setgid و قابل حذف است.

در حال پیکربندی موارد لغو (Android 6.x-7.x)

Android 6.0 fs_config و تعاریف ساختار مرتبط ( system/core/include/private/android_filesystem_config.h ) را به system/core/libcutils/fs_config.c منتقل کرد، جایی که می‌توان آن‌ها را با فایل‌های باینری نصب شده در /system/etc/fs_config_dirs به‌روزرسانی یا لغو کرد. /system/etc/fs_config_files . استفاده از قوانین تطبیق و تجزیه جداگانه برای فهرست‌ها و فایل‌ها (که می‌توانند از عبارات glob اضافی استفاده کنند) اندروید را قادر می‌سازد تا فهرست‌ها و فایل‌ها را در دو جدول مختلف مدیریت کند. تعاریف ساختار در system/core/libcutils/fs_config.c نه تنها خواندن زمان اجرا دایرکتوری‌ها و فایل‌ها را اجازه می‌دهد، بلکه میزبان می‌تواند از همان فایل‌ها در طول زمان ساخت برای ساخت تصاویر سیستم فایل مانند ${OUT}/system/etc/fs_config_dirs و ${OUT}/system/etc/fs_config_files استفاده کند. ${OUT}/system/etc/fs_config_files .

در حالی که روش نادیده گرفتن گسترش سیستم فایل توسط سیستم پیکربندی ماژولار معرفی شده در اندروید 8.0 جایگزین شده است، در صورت تمایل همچنان می توانید از روش قدیمی استفاده کنید. بخش‌های زیر نحوه تولید و گنجاندن فایل‌های جایگزین و پیکربندی سیستم فایل را توضیح می‌دهد.

تولید فایل های نادیده گرفته شده

می توانید فایل های باینری تراز شده /system/etc/fs_config_dirs و /system/etc/fs_config_files را با استفاده از ابزار fs_config_generate در build/tools/fs_config کنید. این ابزار از یک تابع کتابخانه libcutils ( fs_config_generate() ) برای مدیریت الزامات DAC در بافر استفاده می کند و قوانینی را برای یک فایل include تعریف می کند تا قوانین DAC را نهادینه کند.

برای استفاده، یک فایل شامل در device/ vendor / device /android_filesystem_config.h که به عنوان جایگزین عمل می کند. فایل باید از فرمت structure fs_path_config تعریف شده در system/core/include/private/android_filesystem_config.h با مقادیر اولیه ساختار زیر برای نمادهای دایرکتوری و فایل استفاده کند:

  • برای دایرکتوری ها، از android _device _dirs[] استفاده کنید.
  • برای فایل‌ها، از android _device _files[] استفاده کنید.

وقتی از android_device_dirs[] و android_device_files[] استفاده نمی کنید، می توانید NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS و NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_FILES را تعریف کنید (به مثال زیر مراجعه کنید). همچنین می‌توانید با استفاده از TARGET_ANDROID_FILESYSTEM_CONFIG_H در پیکربندی برد، فایل لغو را با نام پایه اجباری android_filesystem_config.h مشخص کنید.

از جمله فایل های لغو

برای اضافه کردن فایل‌ها، مطمئن شوید که PRODUCT_PACKAGES شامل fs_config_dirs و/یا fs_config_files باشد تا بتواند آنها را به ترتیب /system/etc/fs_config_dirs و /system/etc/fs_config_files کند. سیستم ساخت، android_filesystem_config.h سفارشی را در $(TARGET_DEVICE_DIR) جستجو می کند، جایی که BoardConfig.mk وجود دارد. اگر این فایل در جای دیگری وجود دارد، متغیر پیکربندی TARGET_ANDROID_FILESYSTEM_CONFIG_H را تنظیم کنید تا به آن مکان اشاره کند.

پیکربندی فایل سیستم

برای پیکربندی فایل سیستم در اندروید 6.0 و بالاتر:

  1. فایل $(TARGET_DEVICE_DIR)/android_filesystem_config.h را ایجاد کنید.
  2. fs_config_dirs و/یا fs_config_files را به PRODUCT_PACKAGES در فایل پیکربندی برد اضافه کنید (به عنوان مثال، $(TARGET_DEVICE_DIR)/device.mk ).

نادیده گرفتن مثال

این مثال وصله‌ای برای system/bin/glgps برای افزودن پشتیبانی از wake lock در دایرکتوری device/ vendor / device نشان می‌دهد. موارد زیر را در نظر داشته باشید:

  • هر ورودی ساختار حالت، uid، gid، قابلیت ها و نام است. system/core/include/private/android_filesystem_config.h به طور خودکار برای ارائه مانیفست #defines گنجانده شده است ( AID_ROOT ، AID_SHELL ، CAP_BLOCK_SUSPEND ).
  • بخش android_device_files[] شامل اقدامی برای جلوگیری از دسترسی به system/etc/fs_config_dirs در صورت نامشخص است، که به عنوان یک حفاظت اضافی DAC برای کمبود محتوا برای لغو فهرست‌کارها عمل می‌کند. با این حال، این حفاظت ضعیف است. اگر کسی بر /system کنترل داشته باشد، معمولاً می تواند هر کاری را که می خواهد انجام دهد.
diff --git a/android_filesystem_config.h b/android_filesystem_config.h
new file mode 100644
index 0000000..874195f
--- /dev/null
+++ b/android_filesystem_config.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) 2015 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *      http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * permissions and limitations under the License.
+ */
+
+/* This file is used to define the properties of the filesystem
+** images generated by build tools (eg: mkbootfs) and
+** by the device side of adb.
+*/
+
+#define NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS
+/* static const struct fs_path_config android_device_dirs[] = { }; */
+
+/* Rules for files.
+** These rules are applied based on "first match", so they
+** should start with the most specific path and work their
+** way up to the root. Prefixes ending in * denotes wildcard
+** and will allow partial matches.
+*/
+static const struct fs_path_config android_device_files[] = {
+  { 00755, AID_ROOT, AID_SHELL, (1ULL << CAP_BLOCK_SUSPEND),
"system/bin/glgps" },
+#ifdef NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS
+  { 00000, AID_ROOT, AID_ROOT, 0, "system/etc/fs_config_dirs" },
+#endif
+};


diff --git a/device.mk b/device.mk
index 0c71d21..235c1a7 100644
--- a/device.mk
+++ b/device.mk
@@ -18,7 +18,8 @@ PRODUCT_PACKAGES := \
     libwpa_client \
     hostapd \
     wpa_supplicant \
-    wpa_supplicant.conf
+    wpa_supplicant.conf \
+    fs_config_files

 ifeq ($(TARGET_PREBUILT_KERNEL),)
 ifeq ($(USE_SVELTE_KERNEL), true)

انتقال فایل سیستم ها از نسخه های قبلی

هنگام انتقال فایل سیستم ها از Android 5.x و نسخه های قبلی، به خاطر داشته باشید که Android 6.x

  • برخی شامل، ساختارها و تعاریف درون خطی را حذف می کند.
  • به جای اجرای مستقیم از system/core/include/private/android_filesystem_config.h به libcutils نیاز دارد. فایل های اجرایی خصوصی سازنده دستگاه که برای ساختار فایل یا دایرکتوری به system/code/include/private_filesystem_config.h یا fs_config وابسته هستند، باید وابستگی های کتابخانه libcutils را اضافه کنند.
  • برای انتقال به device/ vendor / device /android_filesystem_config.h ، به کپی‌های شاخه خصوصی سازنده دستگاه از system/core/include/private/android_filesystem_config.h با محتوای اضافی روی اهداف موجود نیاز دارد.
  • حق اعمال کنترل‌های دسترسی اجباری SELinux (MAC) را برای فایل‌های پیکربندی در سیستم هدف محفوظ می‌دارد، پیاده‌سازی‌هایی که شامل فایل‌های اجرایی هدف سفارشی با استفاده از fs_config() باید دسترسی را تضمین کنند.