Google متعهد به پیشبرد برابری نژادی برای جوامع سیاه است. ببینید چگونه.
این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.
Switch to English

سفارشی سازی SELinux

بعد از اینکه سطح پایه عملکرد SELinux را یکپارچه کردید و نتایج را به طور کامل تجزیه و تحلیل کردید ، می توانید تنظیمات خط مشی خود را برای پوشش شخصی سازی های خود به سیستم عامل اندروید اضافه کنید. این خط مشی ها باید هنوز الزامات برنامه سازگاری اندرویدی را برآورده سازند و نباید تنظیمات پیش فرض SELinux را حذف کنند.

تولید کنندگان نباید خط مشی موجود SELinux را حذف کنند. در غیر این صورت ، آنها خطر شکستن اجرای Android SELinux و برنامه های حاکم بر آن را دارند. این شامل برنامه های شخص ثالث می شود که برای سازگاری و بهره برداری نیاز به بهبود دارند. برای ادامه کارکردن در دستگاههای با قابلیت SELinux ، برنامه ها برای ایجاد عملکرد نیاز به اصلاح ندارند.

وقتی می خواهید SELinux را شخصی سازی کنید ، به یاد داشته باشید:

  • خط مشی SELinux را برای همه Daemon های جدید بنویسید
  • در هر زمان مناسب از دامنه های از پیش تعریف شده استفاده کنید
  • اختصاص یک دامنه به هر فرآیند باعث به عنوان یک init خدمات
  • قبل از خط مشی با ماکروها آشنا شوید
  • تغییرات در خط مشی اصلی را به AOSP ارسال کنید

و به یاد داشته باشید که:

  • خط مشی ناسازگار ایجاد کنید
  • سفارشی سازی خط مشی کاربر مجاز است
  • مجاز به تنظیمات مربوط به خط مشی MDM
  • کاربران را با نقض خط مشی ترسانید
  • فضای پشتی اضافه کنید

برای نیازهای خاص به بخش ویژگی های امنیتی هسته هسته سند سازگاری Android مراجعه کنید.

SELinux از رویکردی در لیست سفید استفاده می کند ، به این معنی که دسترسی به طور صریح باید در سیاست مجاز باشد تا اعطا شود. از آنجا که خط مشی پیش فرض SELinux Android از پروژه Open Source Android پشتیبانی می کند ، شما لازم نیست که به هیچ وجه تنظیمات SELinux را تغییر دهید. اگر تنظیمات SELinux را سفارشی می کنید ، مراقب باشید که برنامه های موجود را خراب نکنید. برای شروع:

  1. از آخرین هسته Android استفاده کنید .
  2. اصل حداقل امتیاز را تصویب کنید.
  3. فقط آدرس های اضافی خود را به Android آدرس دهید. خط مشی پیش فرض به طور خودکار با برنامه کد منبع باز منبع Android به طور خودکار کار می کند.
  4. اجزای نرم افزار را به ماژول هایی که وظایف مفرد را انجام می دهند ، تقسیم کنید.
  5. سیاست SELinux ایجاد کنید که آن وظایف را از توابع نامربوط جدا کند.
  6. این خط مشی ها را در پرونده های *.te (پسوند پرونده های منبع خط مشی SELinux) در فهرست /device/ manufacturer / device-name /sepolicy و از متغیرهای BOARD_SEPOLICY استفاده کنید تا آنها را در ساخت خود BOARD_SEPOLICY .
  7. دامنه های جدید را ابتدا مجاز کنید. این کار با استفاده از یک اظهارنامه مجاز در پرونده .te دامنه انجام می شود.
  8. نتایج را تجزیه و تحلیل کرده و تعاریف دامنه خود را اصلاح کنید.
  9. اعلامیه مجاز را حذف کنید وقتی هیچ انکار دیگری در ساخت کاربر کاربر وجود ندارد.

بعد از اینکه سیاست تغییر SELinux را یکپارچه کردید ، یک قدم به گردش کار توسعه خود اضافه کنید تا از سازگاری SELinux به جلو بروید. در یک فرآیند توسعه نرم افزار ایده آل ، سیاست SELinux فقط وقتی تغییر می کند که مدل نرم افزار تغییر می کند و نه اجرای واقعی.

وقتی شخصی سازی SELinux را شروع می کنید ، ابتدا افزودنیهای خود را در Android بررسی کنید. اگر مؤلفه ای را اضافه کرده اید که عملکرد جدیدی را انجام می دهد ، قبل از فعال کردن حالت اجرائی ، اطمینان حاصل کنید که این مؤلفه مطابق با سیاست امنیتی Android و همچنین هرگونه خط مشی مرتبط با ساخته شده توسط OEM ، مطابقت دارد.

برای جلوگیری از بروز مشکلات غیرضروری ، بهتر است بیش از حد محدود و ناسازگار از خارج از کشور و بیش از حد سازگار باشید که این امر منجر به خرابی عملکرد دستگاه می شود. در مقابل، اگر تغییرات خود را برای دیگران سودمند خواهد، شما باید تغییرات در سیاست SELinux را به طور پیش فرض به عنوان یک ارائه پچ . اگر پچ به خط مشی امنیتی پیش فرض اعمال شود ، دیگر نیازی به ایجاد این تغییر با هر نسخه جدید Android ندارید.

بیانیه های خط مشی

SELinux مبتنی بر زبان رایانه ای M4 است و به همین دلیل از انواع ماکرو برای صرفه جویی در وقت پشتیبانی می کند.

در مثال زیر ، به همه دامنه ها دسترسی به خواندن یا نوشتن به /dev/null و خواندن از /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 };

این جمله مشابه را می توان با ماکروهای SELinux *_file_perms (بسته کوتاه) *_file_perms :

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

خط مشی مثال

در اینجا یک سیاست کامل برای DHCP آورده شده است ، که در زیر بررسی می کنیم:

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

بیایید مثال را بیان کنیم:

در خط اول ، اعلامیه نوع ، Daemon DHCP از سیاست امنیتی پایه ( domain ) به ارث می برد. از مثال های جمله قبلی ، DHCP می تواند از /dev/null بخواند و بنویسد.

در خط دوم ، DHCP به عنوان یک دامنه مجاز شناخته می شود.

در init_daemon_domain(dhcp) خط، سیاست ایالات DHCP از کلکسیون init و مجاز است به برقراری ارتباط با آن است.

در خط net_domain(dhcp) ، این خط مشی به DHCP اجازه می دهد تا از قابلیت های شبکه مشترک از دامنه net مانند خواندن و نوشتن بسته های TCP ، برقراری ارتباط با سوکت ها و انجام درخواست های DNS استفاده کند.

در خط allow dhcp proc_net:file write; ، خط مشی ایالت DHCP می تواند برای پرونده های خاص در /proc بنویسد. این خط برچسب زدن به پرونده های ریز دانه SELinux را نشان می دهد. از برچسب proc_net برای محدود کردن دسترسی به نوشتن فقط به پرونده های زیر /proc/sys/net .

بلوک نهایی مثال با allow dhcp netd:fd use; شروع allow dhcp netd:fd use; نشان می دهد چگونه برنامه های کاربردی ممکن است مجاز به تعامل با یکدیگر باشند. این سیاست می گوید DHCP و شبکه ممکن است از طریق توصیف کننده پرونده ها ، پرونده های FIFO ، سوکت های دیتاگرام ، و پریزهای جریان UNIX با یکدیگر ارتباط برقرار کنند. DHCP فقط ممکن است از سوکت های datagram و شاخه های جریان UNIX بخواند و بنویسد و آنها را ایجاد یا باز نکند.

کنترل های موجود

کلاس اجازه
فایل
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

بیشتر

و بیشتر

قوانین هرگز

قوانین SELinux neverallow از رفتارهایی که هرگز نباید اتفاق بیفتد منع می کنند. با آزمایش سازگاری ، اکنون قوانین neverallow SELinux در دستگاه ها اجرا نمی شوند.

دستورالعمل های زیر برای کمک به تولید کنندگان در جلوگیری از خطاهای مربوط به قوانین بی neverallow هنگام سفارشی سازی درنظر گرفته شده است. شماره قانون استفاده شده در اینجا با Android 5.1 مطابقت دارد و با انتشار قابل تغییر است.

قانون 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
صفحه ptrace . sys_ptrace قابلیت توانایی اعطا ptrace هر فرایند، که اجازه می دهد تا مقدار زیادی از کنترل بر فرآیندهای دیگر و تنها باید به اجزای سیستم های تعیین شده، مشخص شده در قانون تعلق دارند. نیاز به این قابلیت غالباً حاکی از وجود چیزی است که برای ساخت های کاربرپسند یا عملکردی که مورد نیاز نیست قرار دارد. مؤلفه غیر ضروری را حذف کنید.

قانون 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
این قانون برای جلوگیری از اجرای كد دلخواه در سیستم در نظر گرفته شده است. به طور خاص ، ادعا می کند که فقط کد روی /system اجرا می شود ، که به لطف سازوکارهایی مانند بوت تأیید شده ، تضمین های امنیتی را امکان پذیر می سازد. اغلب ، بهترین راه حل هنگام مواجهه با مشکلی با این قانون بی neverallow ، انتقال کد متخلف به پارتیشن /system .

سفارشی کردن SEPolicy در Android 8.0+

در این بخش دستورالعمل هایی برای سیاست فروشندگان SELinux در Android 8.0 و بالاتر ارائه شده است ، از جمله جزئیات مربوط به پروژه های منبع باز اندروید (AOSP) برنامه های افزودنی SEPolicy و SEPolicy. برای اطلاعات بیشتر در مورد چگونگی حفظ خط مشی SELinux در بین پارتیشن ها و نسخه های Android ، به سازگاری مراجعه کنید.

قرار دادن خط مشی

در Android 7.0 و BOARD_SEPOLICY_DIRS از آن ، سازندگان دستگاه می توانند خط مشی را به BOARD_SEPOLICY_DIRS اضافه کنند ، از جمله خط مشی برای تقویت سیاست AOSP در انواع مختلف دستگاه. در Android نسخه 8.0 و بالاتر ، افزودن خط مشی به BOARD_SEPOLICY_DIRS خط مشی را فقط در تصویر فروشنده قرار می دهد.

در Android 8.0 و بالاتر ، خط مشی در مکان های زیر در AOSP وجود دارد:

  • سیستم / سپهسالاری / عمومی . شامل خط مشی صادر شده برای استفاده در خط مشی خاص فروشنده است. همه چیز به زیرساخت سازگاری آندروید 8.0 می رود. سیاست عمومی به معنای تداوم انتشار در دسترس است ، بنابراین شما می توانید هر چیزی /public در سیاست سفارشی خود گنجانید. به همین دلیل ، نوع سیاستی که می تواند در /public محدودتر است. این را API خط مشی صادر شده این پلتفرم در نظر بگیرید: هر چیزی که با رابط بین /system و /vendor سروکار دارد در اینجا تعلق دارد.
  • سیستم / سپولی / خصوصی . شامل خط مشی لازم برای عملکرد تصویر سیستم است ، اما درباره سیاست های تصویر فروشنده نباید دانش داشته باشد.
  • سیستم / سپولی / فروشنده . شامل خط مشی برای مؤلفه هایی است که وارد /vendor اما در درخت بستر اصلی (نه فهرستهای مخصوص دستگاه) وجود دارند. این مصنوعی از تمایز سیستم ساخت بین دستگاه ها و اجزای جهانی است. از نظر مفهومی این بخشی از خط مشی مخصوص دستگاه است که در زیر شرح داده شده است.
  • دستگاه / manufacturer / device-name / سپوپلی . شامل خط مشی مخصوص دستگاه است. همچنین شامل تنظیمات دستگاه به خط مشی است که در Android 8.0 و بالاتر با خط مشی مربوط به مؤلفه های موجود در تصویر فروشنده مطابقت دارد.

سناریوهای سیاست پشتیبانی می شود

در دستگاه های راه‌اندازی شده با Android 8.0 و بالاتر ، تصویر فروشنده باید با تصویر سیستم OEM و تصویر سیستم مرجع AOSP ارائه شده توسط Google کار کند (و CTS را بر روی این تصویر مرجع بگذارد). این الزامات باعث جدایی تمیز بین چارچوب و کد فروشنده می شود. چنین دستگاه هایی از سناریوهای زیر پشتیبانی می کنند.

برنامه های افزودنی فقط برای تصویر فروشنده

مثال : اضافه کردن سرویس جدید به vndservicemanager از تصویر فروشنده که از پردازش های موجود در تصویر فروشنده پشتیبانی می کند.

همانند راه اندازی دستگاه ها با نسخه های قبلی Android ، سفارشی سازی خاص device/ manufacturer / device-name /sepolicy در device/ manufacturer / device-name /sepolicy . سیاست جدید حاکم بر چگونگی تعامل مؤلفه های فروشنده با (فقط) سایر اجزای فروشنده باید انواع موجود در device/ manufacturer / device-name /sepolicy . خط مشی نوشته شده در اینجا اجازه می دهد تا کد مربوط به فروشنده را کار کند ، به عنوان بخشی از OTA فقط با فریم ورک به روز نمی شود ، و در خط مشی ترکیبی از دستگاه با تصویر سیستم AOSP مرجع حضور خواهد داشت.

پشتیبانی از تصویر فروشنده برای کار با AOSP

مثال : افزودن یک فرآیند جدید (ثبت شده توسط hwservicemanager از تصویر فروشنده) که یک HAL تعریف شده با AOSP را پیاده سازی می کند.

مانند دستگاه های راه‌اندازی شده با نسخه های قبلی Android ، شخصی سازی خاص device/ manufacturer / device-name /sepolicy در device/ manufacturer / device-name /sepolicy . این خط مشی صادر شده به عنوان بخشی از system/sepolicy/public/ برای استفاده در دسترس است و به عنوان بخشی از سیاست فروشندگان ارسال می شود. انواع و ویژگیهای سیاست عمومی ممکن است در قوانین جدیدی که تعامل با بیت های خاص فروشنده جدید را تبیین می کنند ، مورد استفاده قرار گیرد ، مشروط بر محدودیت های مجاز neverallow . همانند مورد فقط فروشنده ، سیاست جدید در اینجا به عنوان بخشی از OTA فقط با فریم ورک به روز نمی شود و در خط مشی ترکیبی از دستگاه با تصویر سیستم AOSP مرجع حضور خواهد داشت.

پسوندهای فقط به سیستم

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

این خط مشی را به system/sepolicy/private . می توانید فرآیندهای اضافی یا اشیاء دیگری را برای فعال کردن عملکرد در تصویر سیستم شریک اضافه کنید ، به شرط آنکه بیت های جدید نیازی به تعامل با مؤلفه های جدید در تصویر فروشنده نداشته باشند (به طور خاص ، چنین فرآیندها یا اشیاء باید بدون خط مشی از تصویر فروشنده کاملاً کار کنند). . خط مشی صادر شده توسط system/sepolicy/public که برای برنامه های افزودنی فقط برای تصویر فروشنده ارائه شده است ، در دسترس است. این خط مشی بخشی از تصویر سیستم است و می تواند در یک OTA فقط با فریم ورک به روز شود ، اما هنگام استفاده از تصویر سیستم مرجع AOSP موجود نخواهد بود.

برنامه های افزودنی تصویر فروشنده که در خدمت اجزای گسترده AOSP است

مثال: HAL جدید و غیر AOSP جدید برای استفاده توسط مشتریهای گسترده که در تصویر سیستم AOSP نیز وجود دارد (مانند سیستم_عامل گسترده).

خط مشی تعامل بین سیستم و فروشنده باید در فهرست device/ manufacturer / device-name /sepolicy که در پارتیشن فروشنده عرضه می شود گنجانده شود. این شبیه به سناریوی فوق برای اضافه کردن پشتیبانی از تصویر فروشنده برای کار با تصویر AOSP مرجع است ، به جز اجزای اصلاح شده AOSP ممکن است به سیاست های اضافی نیز نیاز داشته باشد تا بتواند بقیه پارتیشن سیستم را بطور صحیح کار کند. برچسب های نوع AOSP عمومی را داشته باشید).

خط مشی تعامل مؤلفه های عمومی AOSP با پسوندهای فقط تصویر سیستم باید در system/sepolicy/private باشد.

پسوندهای تصویر سیستم که فقط به رابطهای AOSP دسترسی دارند

مثال: یک سیستم جدید ، بدون AOSP ، باید به HAL که AOSP متکی است دسترسی داشته باشد.

این شبیه به مثال فرمت فقط تصویر سیستم است ، به جز اجزای سیستم جدید ممکن است در رابط system/vendor تعامل داشته باشند. خط مشی برای مؤلفه جدید سیستم باید به صورت system/sepolicy/private ، که قابل قبول است از طریق رابط کاربری که قبلاً توسط system/sepolicy/public در system/sepolicy/public (یعنی انواع و ویژگی های مورد نیاز برای عملکرد وجود دارد). در حالیکه این خط مشی می تواند در خط مشی مخصوص دستگاه گنجانده شود ، نمی تواند در نتیجه بروزرسانی تنها چارچوب ، از system/sepolicy/private دیگر system/sepolicy/private انواع system/sepolicy/private یا تغییر (به هر روشی که مؤثر باشد) استفاده کند. این خط مشی ممکن است فقط در یک فریم ورک OTA تغییر یابد ، اما هنگام استفاده از تصویر سیستم AOSP (که اجزای سیستم جدید را نیز ندارد) حضور نخواهد داشت.

برنامه های افزودنی تصویر فروشنده که در خدمت اجزای سیستم جدید است

مثال: افزودن HAL جدید غیر AOSP برای استفاده توسط فرآیند مشتری بدون آنالوگ AOSP (و بنابراین به دامنه خاص خود نیاز دارد).

مشابه با مثال AOSP-extensions ، خط مشی تعامل بین سیستم و فروشنده باید در فهرست device/ manufacturer / device-name /sepolicy حمل شده روی پارتیشن فروشنده قرار گیرد (برای اطمینان از اینکه سیاست سیستم هیچ آگاهی از جزئیات خاص فروشنده) ندارد. شما می توانید انواع عمومی جدیدی را اضافه کنید که سیاست را در system/sepolicy/public گسترش می دهد. این باید فقط علاوه بر سیاست AOSP موجود انجام شود ، یعنی سیاست های عمومی AOSP را حذف نکنید. انواع جدید عمومی سپس می توانند برای خط مشی در system/sepolicy/private و در device/ manufacturer / device-name /sepolicy .

به خاطر داشته باشید که هر system/sepolicy/public با افشای یک ضمانت سازگاری جدید که باید در یک فایل نقشه برداری ردیابی شود و مشمول محدودیت های دیگر system/sepolicy/public ، پیچیدگی را اضافه می کند. فقط انواع جدید و قوانین مجاز مربوطه ممکن است در system/sepolicy/public . ویژگی ها و سایر بیانیه های سیاست پشتیبانی نمی شوند. علاوه بر این ، از انواع جدید عمومی نمی توان برای برچسب زدن مستقیم اشیاء در سیاست /vendor کرد.

سناریوهای سیاست پشتیبانی نشده

راه اندازی دستگاه هایی با Android 8.0 و بالاتر از سناریوی خط مشی زیر و مثال ها پشتیبانی نمی کند.

پسوندهای اضافی به تصویر سیستم که به اجزای جدید تصویر فروشنده پس از OTA فقط با چارچوب نیاز دارند

مثال: یک سیستم جدید غیر AOSP ، که به دامنه خود نیاز دارد ، در نسخه بعدی Android اضافه شده و نیاز به دسترسی به HAL جدید غیر AOSP دارد.

مشابه سیستم جدید (غیر AOSP) و تعامل با مؤلفه های فروشنده ، به جز نوع سیستم جدید در OTA فقط با فریم ورک معرفی شده است. اگرچه می توان نوع جدیدی را در system/sepolicy/public ، اما سیاست فروشندگان موجود هیچ آگاهی از نوع جدید ندارند زیرا فقط سیاست عمومی سیستم 8.0 Android را ردیابی می کند. AOSP با افشای منابع تأمین شده از طریق فروشنده از طریق یک ویژگی (مثلاً ویژگی hal_foo ) این کار را انجام می دهد ، اما از آنجا که پسوندهای شریک ویژگی در system/sepolicy/public پشتیبانی نمی شوند ، این روش برای سیاست فروشندگان در دسترس نیست. دسترسی باید از طریق نوع عمومی قبلی موجود باشد.

مثال: تغییر در یک فرآیند سیستم (AOSP یا غیر AOSP) باید نحوه تعامل با مؤلفه فروشنده جدید غیر AOSP را تغییر دهد.

خط مشی مربوط به تصویر سیستم باید بدون اطلاع از موارد سفارشی خاص فروشنده باشد. بنابراین خط مشی مربوط به واسطهای خاص در AOSP از طریق ویژگیهای سیستم / سیستمیک / عمومی در معرض دید قرار می گیرد تا سیاست فروشندگان بتوانند از سیاستهای آینده سیستم که از این خصوصیات استفاده می کند ، انتخاب کنند. حال، پسوند صفت در system/sepolicy/public پشتیبانی نمی شوند، به طوری که همه تحمیل سیاست چگونه اجزای سیستم تعامل با اجزای فروشنده جدید (و است که با ویژگی های در حال حاضر در AOSP حاضر به کار گرفته نمی system/sepolicy/public ) باید در device/ manufacturer / device-name /sepolicy . این بدان معنی است که انواع سیستم نمی توانند دسترسی مجاز به انواع فروشنده را به عنوان بخشی از OTA فقط با فریم ورک تغییر دهند.