27 মার্চ, 2025 থেকে, আমরা AOSP তৈরি করতে এবং অবদান রাখতে aosp-main এর পরিবর্তে android-latest-release ব্যবহার করার পরামর্শ দিচ্ছি। আরও তথ্যের জন্য, AOSP-তে পরিবর্তনগুলি দেখুন।

এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

নীতি সামঞ্জস্য, নীতি সামঞ্জস্য, নীতি সামঞ্জস্য, নীতি সামঞ্জস্য

এই পৃষ্ঠাটি বর্ণনা করে যে Android কীভাবে প্ল্যাটফর্ম ওভার-দ্য-এয়ার (OTA) আপডেটগুলির সাথে নীতি সামঞ্জস্যপূর্ণ সমস্যাগুলি পরিচালনা করে, যেখানে নতুন প্ল্যাটফর্ম SELinux সেটিংস পুরানো বিক্রেতা SELinux সেটিংস থেকে আলাদা হতে পারে৷

বস্তুর মালিকানা এবং লেবেলিং

প্ল্যাটফর্ম এবং বিক্রেতা নীতি আলাদা রাখতে প্রতিটি বস্তুর জন্য মালিকানা স্পষ্টভাবে সংজ্ঞায়িত করা আবশ্যক। উদাহরণস্বরূপ, যদি পরবর্তী OTA-তে ভেন্ডর পলিসি লেবেল /dev/foo এবং প্ল্যাটফর্ম নীতি লেবেল /dev/foo থাকে, তাহলে একটি অপ্রত্যাশিত অস্বীকার বা আরও সমালোচনামূলকভাবে, বুট ব্যর্থতার মতো অনির্ধারিত আচরণ রয়েছে। SELinux-এর জন্য, এটি একটি লেবেলিং সংঘর্ষ হিসাবে প্রকাশ পায়। ডিভাইস নোডে শুধুমাত্র একটি একক লেবেল থাকতে পারে যা শেষ যেটি লেবেল প্রয়োগ করা হয় তার সমাধান করে। ফলস্বরূপ:

ব্যর্থভাবে প্রয়োগ করা লেবেলে অ্যাক্সেসের প্রয়োজন এমন প্রক্রিয়াগুলি সম্পদের অ্যাক্সেস হারায়।
ভুল ডিভাইস নোড তৈরি হওয়ার কারণে ফাইলে অ্যাক্সেস পাওয়া প্রক্রিয়াগুলি ভেঙে যেতে পারে।

প্ল্যাটফর্ম এবং বিক্রেতা লেবেলের মধ্যে সংঘর্ষ ঘটতে পারে যেকোন বস্তুর জন্য যার একটি SELinux লেবেল আছে, বৈশিষ্ট্য, পরিষেবা, প্রক্রিয়া, ফাইল এবং সকেট সহ। এই সমস্যাগুলি এড়াতে, এই বস্তুগুলির মালিকানা স্পষ্টভাবে সংজ্ঞায়িত করুন।

টাইপ/অ্যাট্রিবিউট নেমস্পেসিং

লেবেল সংঘর্ষের পাশাপাশি, SELinux টাইপ এবং অ্যাট্রিবিউটের নামগুলিও সংঘর্ষ হতে পারে। SELinux একই ধরনের এবং গুণাবলীর একাধিক ঘোষণা অনুমোদন করে না। ডুপ্লিকেট ঘোষণা সহ একটি নীতি কম্পাইল করতে ব্যর্থ হয়। টাইপ এবং অ্যাট্রিবিউট নামের সংঘর্ষ এড়াতে, সমস্ত বিক্রেতার ঘোষণাকে vendor_ উপসর্গ দিয়ে শুরু করার জন্য অত্যন্ত সুপারিশ করা হয়। উদাহরণস্বরূপ, বিক্রেতাদের type vendor_foo, domain; type foo, domain; .

ফাইলের মালিকানা

ফাইলগুলির সংঘর্ষ প্রতিরোধ করা চ্যালেঞ্জিং কারণ প্ল্যাটফর্ম এবং বিক্রেতা নীতি উভয়ই সাধারণত সমস্ত ফাইল সিস্টেমের জন্য লেবেল সরবরাহ করে। টাইপ নামকরণের বিপরীতে, ফাইলগুলির নামস্থান ব্যবহারিক নয় কারণ তাদের অনেকগুলি কার্নেল দ্বারা তৈরি করা হয়। এই সংঘর্ষগুলি প্রতিরোধ করতে, এই বিভাগে ফাইল সিস্টেমের নামকরণ নির্দেশিকা অনুসরণ করুন। Android 8.0-এর জন্য, এইগুলি প্রযুক্তিগত প্রয়োগ ছাড়াই সুপারিশ। ভবিষ্যতে, এই সুপারিশগুলি ভেন্ডর টেস্ট স্যুট (VTS) দ্বারা প্রয়োগ করা হবে৷

সিস্টেম (/সিস্টেম)

শুধুমাত্র সিস্টেম ইমেজ অবশ্যই /system উপাদানগুলির জন্য file_contexts , service_contexts , ইত্যাদির মাধ্যমে লেবেল প্রদান করবে৷ যদি /system উপাদানগুলির জন্য লেবেলগুলি বিক্রেতা নীতিতে যোগ করা হয়, একটি কাঠামো-শুধু OTA আপডেট সম্ভব নাও হতে পারে৷

বিক্রেতা (/বিক্রেতা)

AOSP SELinux পলিসি ইতিমধ্যেই প্ল্যাটফর্মের সাথে ইন্টারঅ্যাক্ট করে এমন vendor পার্টিশনের অংশগুলিকে লেবেল করে, যা প্ল্যাটফর্মের প্রক্রিয়াগুলির জন্য SELinux নিয়মগুলিকে vendor পার্টিশনের অংশগুলিতে কথা বলতে বা অ্যাক্সেস করতে সক্ষম করে। উদাহরণ:

/ বিক্রেতা পথ	প্ল্যাটফর্ম-প্রদত্ত লেবেল	প্ল্যাটফর্ম প্রক্রিয়া লেবেলের উপর নির্ভর করে
`/vendor(/. * )?`	`vendor_file`	ফ্রেমওয়ার্ক, `ueventd` , ইত্যাদিতে সমস্ত HAL ক্লায়েন্ট।
`/vendor/framework(/. * )?`	`vendor_framework_file`	`dex2oat` , `appdomain` , ইত্যাদি
`/vendor/app(/. * )?`	`vendor_app_file`	`dex2oat` , `installd` , `idmap` , ইত্যাদি।
`/vendor/overlay(/. * )`	`vendor_overlay_file`	`system_server` , `zygote` , `idmap` , ইত্যাদি

ফলস্বরূপ, vendor পার্টিশনে অতিরিক্ত ফাইল লেবেল করার সময় নির্দিষ্ট নিয়মগুলি অবশ্যই অনুসরণ করতে হবে ( neverallows এর মাধ্যমে প্রয়োগ করা হয়েছে):

vendor_file অবশ্যই vendor পার্টিশনের সমস্ত ফাইলের জন্য ডিফল্ট লেবেল হতে হবে। পাসথ্রু HAL বাস্তবায়ন অ্যাক্সেস করার জন্য প্ল্যাটফর্ম নীতির এটি প্রয়োজন।
ভেন্ডর পলিসির মাধ্যমে vendor পার্টিশনে যোগ করা সমস্ত নতুন exec_types এর অবশ্যই vendor_file_type অ্যাট্রিবিউট থাকতে হবে। এটি neverallows মাধ্যমে প্রয়োগ করা হয়.
ভবিষ্যতের প্ল্যাটফর্ম/ফ্রেমওয়ার্ক আপডেটের সাথে দ্বন্দ্ব এড়াতে, vendor পার্টিশনে exec_types ছাড়া অন্য ফাইলগুলিকে লেবেল করা এড়িয়ে চলুন।
AOSP- সনাক্তকৃত একই প্রক্রিয়া HAL-এর জন্য সমস্ত লাইব্রেরি নির্ভরতাকে same_process_hal_file.

Procfs (/proc)

/proc এর ফাইলগুলি শুধুমাত্র genfscon লেবেল ব্যবহার করে লেবেল করা হতে পারে। Android 7.0-এ, প্ল্যাটফর্ম এবং বিক্রেতা নীতি উভয়ই genfscon ব্যবহার করে ফাইলগুলিকে procfs এ লেবেল করতে।

সুপারিশ: শুধুমাত্র প্ল্যাটফর্ম নীতি লেবেল /proc । যদি বিক্রেতা প্রক্রিয়াগুলির /proc এ ফাইলগুলিতে অ্যাক্সেসের প্রয়োজন হয় যেগুলি বর্তমানে ডিফল্ট লেবেল ( proc ) দিয়ে লেবেল করা আছে, তবে বিক্রেতা নীতির তাদের স্পষ্টভাবে লেবেল করা উচিত নয় এবং এর পরিবর্তে বিক্রেতা ডোমেনের জন্য নিয়মগুলি যোগ করতে জেনেরিক proc প্রকার ব্যবহার করা উচিত। এটি প্ল্যাটফর্ম আপডেটগুলিকে procfs মাধ্যমে উন্মোচিত ভবিষ্যতের কার্নেল ইন্টারফেসগুলিকে সামঞ্জস্য করার অনুমতি দেয় এবং প্রয়োজন অনুসারে স্পষ্টভাবে লেবেল করে।

Debugfs (/sys/kernel/debug)

Debugfs file_contexts এবং genfscon উভয় ক্ষেত্রেই লেবেল করা যেতে পারে। Android 7.0 থেকে Android 10-এ, উভয় প্ল্যাটফর্ম এবং বিক্রেতা লেবেল debugfs ।

অ্যান্ড্রয়েড 11-এ, debugfs অ্যাক্সেস করা যাবে না বা প্রোডাকশন ডিভাইসে মাউন্ট করা যাবে না। ডিভাইস নির্মাতাদের debugfs অপসারণ করা উচিত।

Tracefs (/sys/kernel/debug/tracing)

Tracefs file_contexts এবং genfscon উভয় ক্ষেত্রেই লেবেল করা যেতে পারে। অ্যান্ড্রয়েড 7.0-এ, শুধুমাত্র প্ল্যাটফর্মের লেবেল tracefs ।

সুপারিশ: শুধুমাত্র প্ল্যাটফর্ম tracefs লেবেল করতে পারে।

Sysfs (/sys)

/sys এ ফাইলগুলি file_contexts এবং genfscon উভয় ব্যবহার করে লেবেল করা হতে পারে। অ্যান্ড্রয়েড 7.0-এ, প্ল্যাটফর্ম এবং বিক্রেতা উভয়ই sysfs এ ফাইল লেবেল করতে genfscon ব্যবহার করে।

প্রস্তাবনা: প্ল্যাটফর্মটি sysfs নোডগুলিকে লেবেল করতে পারে যা ডিভাইস-নির্দিষ্ট নয়। অন্যথায়, শুধুমাত্র বিক্রেতা ফাইল লেবেল করতে পারে.

tmpfs (/dev)

/dev এর ফাইলগুলি file_contexts এ লেবেল করা হতে পারে। অ্যান্ড্রয়েড 7.0-এ, প্ল্যাটফর্ম এবং বিক্রেতা লেবেল উভয়ই এখানে ফাইল রয়েছে।

সুপারিশ: বিক্রেতা শুধুমাত্র /dev/vendor এ ফাইলগুলি লেবেল করতে পারে (উদাহরণস্বরূপ, /dev/vendor/foo , /dev/vendor/socket/bar )।

Rootfs (/)

/ file_contexts এ লেবেল করা হতে পারে। অ্যান্ড্রয়েড 7.0-এ, প্ল্যাটফর্ম এবং বিক্রেতা উভয় লেবেল ফাইল এখানে।

সুপারিশ: শুধুমাত্র সিস্টেম / এ ফাইলগুলি লেবেল করতে পারে।

ডেটা (/ডেটা)

file_contexts এবং seapp_contexts এর সমন্বয়ের মাধ্যমে ডেটা লেবেল করা হয়।

প্রস্তাবনা: /data/vendor বাইরে বিক্রেতা লেবেলিং অস্বীকৃত করুন। শুধুমাত্র প্ল্যাটফর্ম /data এর অন্যান্য অংশ লেবেল করতে পারে।

Genfs লেবেল সংস্করণ

ভেন্ডর এপিআই লেভেল 202504 দিয়ে শুরু করে, system/sepolicy/compat/plat_sepolicy_genfs_ ver .cil এ genfscon সাথে বরাদ্দ করা নতুন SELinux লেবেলগুলি পুরানো vendor পার্টিশনের জন্য ঐচ্ছিক। এটি পুরানো vendor পার্টিশনগুলিকে তাদের বিদ্যমান এসইপলিসি বাস্তবায়ন রাখতে দেয়। এটি মেকফাইল ভেরিয়েবল BOARD_GENFS_LABELS_VERSION দ্বারা নিয়ন্ত্রিত যা /vendor/etc/selinux/genfs_labels_version.txt এ সংরক্ষিত।

উদাহরণ:

বিক্রেতা API স্তর 202404-এ, /sys/class/udc নোডকে ডিফল্টরূপে sysfs লেবেল করা হয়।
বিক্রেতা API স্তর 202504 থেকে শুরু করে, /sys/class/udc sysfs_udc লেবেল করা হয়েছে।

যাইহোক, ডিফল্ট sysfs লেবেল বা ভেন্ডর-নির্দিষ্ট লেবেল সহ, API স্তর 202404 ব্যবহার করে vendor পার্টিশন দ্বারা /sys/class/udc ব্যবহার করা হতে পারে। শর্তহীনভাবে /sys/class/udc হিসাবে sysfs_udc লেবেল করা এই vendor পার্টিশনগুলির সাথে সামঞ্জস্য নষ্ট করতে পারে। BOARD_GENFS_LABELS_VERSION চেক করে, প্ল্যাটফর্মটি পুরানো vendor পার্টিশনগুলির জন্য পূর্ববর্তী লেবেল এবং অনুমতিগুলি ব্যবহার করে চলেছে৷

BOARD_GENFS_LABELS_VERSION বিক্রেতা API স্তরের চেয়ে বড় বা সমান হতে পারে৷ উদাহরণস্বরূপ, API স্তর 202404 ব্যবহার করে vendor পার্টিশনগুলি 202504-এ প্রবর্তিত নতুন লেবেল গ্রহণের জন্য BOARD_GENFS_LABELS_VERSION 202504-এ সেট করতে পারে৷ 202504-নির্দিষ্ট genfs লেবেলগুলির তালিকা দেখুন৷

genfscon নোডগুলিকে লেবেল করার সময়, প্ল্যাটফর্মটিকে অবশ্যই পুরানো vendor পার্টিশন বিবেচনা করতে হবে এবং প্রয়োজনের সময় সামঞ্জস্যের জন্য ফলব্যাক পদ্ধতি প্রয়োগ করতে হবে। প্ল্যাটফর্মটি genfs লেবেল সংস্করণ অনুসন্ধান করতে প্ল্যাটফর্ম-শুধু লাইব্রেরি ব্যবহার করতে পারে।

নেটিভ এ, libgenfslabelsversion ব্যবহার করুন। libgenfslabelsversion এর হেডার ফাইলের জন্য genfslabelsversion.h দেখুন।
জাভাতে, android.os.SELinux.getGenfsLabelsVersion() ব্যবহার করুন।

প্ল্যাটফর্ম-পাবলিক নীতি

প্ল্যাটফর্ম SELinux নীতি ব্যক্তিগত এবং সর্বজনীন বিভক্ত। প্ল্যাটফর্ম-পাবলিক নীতিতে এমন প্রকার এবং বৈশিষ্ট্য রয়েছে যা সর্বদা একটি ভেন্ডর API স্তরের জন্য উপলব্ধ থাকে, প্ল্যাটফর্ম এবং বিক্রেতার মধ্যে একটি API হিসাবে কাজ করে৷ এই নীতিটি বিক্রেতা নীতি লেখকদের কাছে প্রকাশ করা হয় যাতে বিক্রেতাদের বিক্রেতা নীতি ফাইল তৈরি করতে সক্ষম করে, যা প্ল্যাটফর্ম-প্রাইভেট নীতির সাথে একত্রিত হলে, একটি ডিভাইসের জন্য একটি সম্পূর্ণ কার্যকরী নীতিতে পরিণত হয়। প্ল্যাটফর্ম-পাবলিক নীতি system/sepolicy/public এ সংজ্ঞায়িত করা হয়েছে।

উদাহরণস্বরূপ, একটি প্রকার vendor_init , বিক্রেতার প্রসঙ্গে init প্রক্রিয়ার প্রতিনিধিত্ব করে, system/sepolicy/public/vendor_init.te এর অধীনে সংজ্ঞায়িত করা হয়েছে:

type vendor_init, domain;

কাস্টম নীতির নিয়ম লিখতে বিক্রেতারা vendor_init টাইপটি উল্লেখ করতে পারেন:

# Allow vendor_init to set vendor_audio_prop in vendor's init scripts
set_prop(vendor_init, vendor_audio_prop)

সামঞ্জস্যপূর্ণ বৈশিষ্ট্য

SELinux পলিসি হল নির্দিষ্ট অবজেক্ট ক্লাস এবং অনুমতির জন্য উৎস এবং লক্ষ্য প্রকারের মধ্যে একটি মিথস্ক্রিয়া। SELinux নীতি দ্বারা প্রভাবিত প্রতিটি বস্তু (উদাহরণস্বরূপ, প্রসেস, ফাইল) শুধুমাত্র একটি টাইপ থাকতে পারে, কিন্তু সেই ধরনের একাধিক বৈশিষ্ট্য থাকতে পারে।

নীতিটি বেশিরভাগ বিদ্যমান প্রকারের পরিপ্রেক্ষিতে লেখা হয়। এখানে, vendor_init এবং debugfs উভয় প্রকার:

allow vendor_init debugfs:dir { mounton };

এটি কাজ করে কারণ নীতিটি সমস্ত ধরণের জ্ঞান দিয়ে লেখা হয়েছিল। যাইহোক, যদি বিক্রেতা নীতি এবং প্ল্যাটফর্ম নীতি নির্দিষ্ট প্রকারগুলি ব্যবহার করে এবং একটি নির্দিষ্ট বস্তুর লেবেল শুধুমাত্র সেই নীতিগুলির একটিতে পরিবর্তিত হয়, অন্যটিতে এমন নীতি থাকতে পারে যা পূর্বে নির্ভর করা অ্যাক্সেস লাভ করেছে বা হারিয়েছে৷ উদাহরণস্বরূপ, ধরুন যে প্ল্যাটফর্ম নীতি sysfs নোডগুলিকে sysfs হিসাবে লেবেল করে:

/sys(/.*)? u:object_r:sysfs:s0

বিক্রেতা নীতি sysfs হিসাবে লেবেলযুক্ত /sys/usb এ অ্যাক্সেস প্রদান করে:

allow vendor_init sysfs:chr_file rw_file_perms;

যদি প্ল্যাটফর্ম নীতি /sys/usb sysfs_usb লেবেলে পরিবর্তন করা হয়, তবে বিক্রেতা নীতি একই থাকবে, কিন্তু নতুন sysfs_usb ধরনের নীতির অভাবের কারণে vendor_init /sys/usb এ অ্যাক্সেস হারায়:

/sys/usb u:object_r:sysfs_usb:s0

এই সমস্যাটি সমাধান করার জন্য, Android সংস্করণযুক্ত বৈশিষ্ট্যগুলির একটি ধারণা প্রবর্তন করে। কম্পাইলের সময়, বিল্ড সিস্টেম স্বয়ংক্রিয়ভাবে প্ল্যাটফর্মের পাবলিক টাইপগুলিকে বিক্রেতা নীতিতে ব্যবহৃত এই সংস্করণযুক্ত বৈশিষ্ট্যগুলিতে অনুবাদ করে। এই অনুবাদটি প্ল্যাটফর্ম থেকে এক বা একাধিক পাবলিক টাইপের সাথে একটি সংস্করণযুক্ত বৈশিষ্ট্যকে সংযুক্ত করে এমন ফাইল ম্যাপিং দ্বারা সক্ষম করা হয়েছে৷

উদাহরণস্বরূপ, ধরুন যে 202504 প্ল্যাটফর্ম নীতিতে /sys/usb sysfs হিসাবে লেবেল করা হয়েছে, এবং 202504 বিক্রেতা নীতি vendor_init /sys/usb এ অ্যাক্সেস দেয়। এই ক্ষেত্রে:

ভেন্ডর পলিসি একটি নিয়ম লেখে allow vendor_init sysfs:chr_file rw_file_perms; , কারণ 202504 প্ল্যাটফর্ম নীতিতে /sys/usb sysfs হিসাবে লেবেল করা হয়েছে। যখন বিল্ড সিস্টেম ভেন্ডর পলিসি কম্পাইল করে, তখন এটি স্বয়ংক্রিয়ভাবে নিয়মটিকে allow vendor_init _202504 sysfs _202504 :chr_file rw_file_perms; . vendor_init_202504 এবং sysfs_202504 বৈশিষ্ট্যগুলি vendor_init এবং sysfs প্রকারের সাথে মিলে যায়, যা প্ল্যাটফর্ম দ্বারা সংজ্ঞায়িত প্রকার।
বিল্ড সিস্টেম একটি আইডেন্টিটি ম্যাপিং ফাইল তৈরি করে /system/etc/selinux/mapping/202504.cil । যেহেতু system এবং vendor পার্টিশন উভয়ই একই 202504 সংস্করণ ব্যবহার করে, ম্যাপিং ফাইলটিতে type_202504 থেকে type পর্যন্ত পরিচয় ম্যাপিং রয়েছে। উদাহরণস্বরূপ, vendor_init_202504 ম্যাপ করা হয়েছে vendor_init , এবং sysfs_202504 sysfs এ ম্যাপ করা হয়েছে:
```
(typeattributeset sysfs_202504 (sysfs))
(typeattributeset vendor_init_202504 (vendor_init))
...
```

যখন সংস্করণটি 202504 থেকে 202604 পর্যন্ত বাম্প করা হয়, তখন 202504 vendor পার্টিশনের জন্য একটি নতুন ম্যাপিং ফাইল system/sepolicy/private/compat/202504/202504.cil এর অধীনে তৈরি করা হয়, যা /system/etc/selinux/mapping/202504.cil selinux/mapping 20204/এর জন্য ইনস্টল করা হয়। নতুন system পার্টিশন। প্রাথমিকভাবে, এই ম্যাপিং ফাইলে পরিচয় ম্যাপিং রয়েছে, যেমনটি পূর্বে বর্ণিত হয়েছে। যদি 202604 প্ল্যাটফর্ম নীতিতে /sys/usb এর জন্য একটি নতুন লেবেল sysfs_usb যোগ করা হয়, ম্যাপিং ফাইলটি sysfs_202504 ম্যাপ sysfs_usb এ আপডেট করা হয়:

(typeattributeset sysfs_202504 (sysfs sysfs_usb))
(typeattributeset vendor_init_202504 (vendor_init))
...

এই আপডেটটি রূপান্তরিত বিক্রেতা নীতির নিয়মকে allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms; নতুন sysfs_usb প্রকারে স্বয়ংক্রিয়ভাবে vendor_init অ্যাক্সেস মঞ্জুর করতে।

পুরানো vendor পার্টিশনের সাথে সামঞ্জস্য বজায় রাখার জন্য, যখনই একটি নতুন পাবলিক টাইপ যোগ করা হয়, সেই টাইপটিকে ম্যাপিং ফাইল system/sepolicy/private/compat/ ver / ver .cil মধ্যে অন্তত একটি সংস্করণযুক্ত বৈশিষ্ট্যের সাথে ম্যাপ করতে হবে, অথবা system/sepolicy/private/compat/ ver / ver .ignore.cil অধীনে তালিকাভুক্ত হতে হবে অথবা পূর্ববর্তী সংস্করণের সাথে মিল না থাকলে তা উপেক্ষা করা হবে না।

প্ল্যাটফর্ম নীতি, বিক্রেতা নীতি এবং ম্যাপিং ফাইলের সমন্বয় সিস্টেমকে বিক্রেতা নীতি আপডেট না করেই আপডেট করার অনুমতি দেয়। এছাড়াও সংস্করণযুক্ত বৈশিষ্ট্যগুলিতে রূপান্তর স্বয়ংক্রিয়ভাবে ঘটে, তাই বিক্রেতা নীতির সংস্করণের যত্ন নেওয়ার দরকার নেই, সর্বজনীন প্রকারগুলিকে যেমন আছে তেমন ব্যবহার করে।

দ্রষ্টব্য: পূর্বে উল্লিখিত সর্বজনীন প্রকারের বিপরীতে সর্বজনীন বৈশিষ্ট্যগুলি সংস্করণ করা হয় না। বৈশিষ্ট্যগুলি নির্দিষ্ট ধরণের নয় এবং বৈশিষ্ট্যগুলিকে দেওয়া অনুমতিগুলি স্বয়ংক্রিয়ভাবে সমস্ত ধরণের ক্ষেত্রে প্রয়োগ করা হয় যা বৈশিষ্ট্যের সাথে মানচিত্র তৈরি করে৷ উদাহরণস্বরূপ, যদি কোনো বিক্রেতা নীতি appdomain অনুমতি দেয়, অনুমতিগুলি স্বয়ংক্রিয়ভাবে সমস্ত অ্যাপে প্রয়োগ করা হয়, যার মধ্যে নতুন সিস্টেম অ্যাপ্লিকেশানগুলি সহ যেগুলি নীতিটি লেখার সময় বিদ্যমান ছিল না৷

system_ext পাবলিক এবং পণ্য পাবলিক নীতি

অ্যান্ড্রয়েড 11 থেকে শুরু করে, system_ext এবং product পার্টিশনগুলিকে তাদের মনোনীত পাবলিক ধরনের vendor পার্টিশনে রপ্তানি করার অনুমতি দেওয়া হয়েছে। প্ল্যাটফর্ম পাবলিক পলিসির মতো, বিক্রেতা নীতি স্বয়ংক্রিয়ভাবে সংস্করণযুক্ত বৈশিষ্ট্যগুলিতে অনুবাদ করা প্রকার এবং নিয়ম ব্যবহার করে, উদাহরণস্বরূপ, type থেকে type_ ver , যেখানে ver হল vendor পার্টিশনের ভেন্ডর API স্তর।

যখন system_ext এবং product পার্টিশনগুলি একই প্ল্যাটফর্ম সংস্করণ ver উপর ভিত্তি করে তৈরি হয়, তখন বিল্ড সিস্টেম system_ext/etc/selinux/mapping/ ver .cil এবং product/etc/selinux/mapping/ ver .cil এ বেস ম্যাপিং ফাইল তৈরি করে, যাতে type থেকে type_ ver পর্যন্ত আইডেন্টিটি ম্যাপিং থাকে। ভেন্ডর পলিসি ভার্সনড অ্যাট্রিবিউট type_ ver দিয়ে type অ্যাক্সেস করতে পারে।

যে ক্ষেত্রে শুধুমাত্র system_ext এবং product পার্টিশন আপডেট করা হয়, ver থেকে ver+1 (বা পরে) বলুন, যখন vendor পার্টিশন ver এ থাকে, ভেন্ডর পলিসি system_ext এবং product পার্টিশনের ধরনগুলিতে অ্যাক্সেস হারাতে পারে। ভাঙ্গন রোধ করার জন্য, system_ext এবং product পার্টিশনগুলিকে কংক্রিট ধরনের থেকে type_ ver বৈশিষ্ট্যগুলিতে ম্যাপিং ফাইল সরবরাহ করা উচিত। প্রতিটি অংশীদার ম্যাপিং ফাইল রক্ষণাবেক্ষণের জন্য দায়ী, যদি তারা ver+1 (বা পরবর্তী) system_ext এবং product পার্টিশন সহ ver vendor পার্টিশন সমর্থন করে।

system_ext এবং product পার্টিশনে ম্যাপিং ফাইল ইনস্টল করতে, ডিভাইস বাস্তবায়নকারী বা বিক্রেতারা আশা করা হচ্ছে:

ver system_ext এবং product পার্টিশন থেকে উৎপন্ন বেস ম্যাপিং ফাইলগুলিকে তাদের উত্স ট্রিতে অনুলিপি করুন।
প্রয়োজন অনুসারে ম্যাপিং ফাইলগুলি সংশোধন করুন।
ver+1 (বা পরবর্তী) system_ext এবং product পার্টিশনে ম্যাপিং ফাইল ইনস্টল করুন ।

উদাহরণস্বরূপ, ধরুন যে 202504 system_ext পার্টিশনে foo_type নামে একটি পাবলিক টাইপ রয়েছে। তারপর 202504 system_ext পার্টিশনে system_ext/etc/selinux/mapping/202504.cil এইরকম দেখায়:

(typeattributeset foo_type_202504 (foo_type))
(expandtypeattribute foo_type_202504 true)
(typeattribute foo_type_202504)

যদি bar_type 202604 system_ext এ যোগ করা হয় এবং 202504 vendor পার্টিশনের জন্য foo_type এ bar_type ম্যাপ করা হয়, 202504.cil (typeattributeset foo_type_202504 (foo_type)) (typeattributeset foo_type_202504 (foo_type bar_type)) থেকে আপডেট করা যেতে পারে। (typeattributeset foo_type_202504 (foo_type bar_type)) এবং তারপর 202604 system_ext পার্টিশনে ইনস্টল করা হয়। 202504 vendor পার্টিশন 202604 system_ext এর foo_type এবং bar_type এ অ্যাক্সেস করা চালিয়ে যেতে পারে।

অ্যান্ড্রয়েড 9 এর জন্য বৈশিষ্ট্য পরিবর্তন

Android 9 এ আপগ্রেড করা ডিভাইসগুলি নিম্নলিখিত বৈশিষ্ট্যগুলি ব্যবহার করতে পারে, তবে Android 9 এর সাথে চালু হওয়া ডিভাইসগুলি অবশ্যই নয়৷

লঙ্ঘনকারী বৈশিষ্ট্য

Android 9 এই ডোমেন-সম্পর্কিত বৈশিষ্ট্যগুলি অন্তর্ভুক্ত করে:

data_between_core_and_vendor_violators । vendor এবং coredomains মধ্যে পাথ দ্বারা ফাইলগুলি ভাগ না করার প্রয়োজনীয়তা লঙ্ঘন করে এমন সমস্ত ডোমেনের জন্য বৈশিষ্ট্য৷ প্ল্যাটফর্ম এবং বিক্রেতা প্রক্রিয়াগুলি যোগাযোগের জন্য অন-ডিস্ক ফাইলগুলি ব্যবহার করা উচিত নয় (অস্থির ABI)। সুপারিশ:
- বিক্রেতা কোড /data/vendor ব্যবহার করা উচিত।
- সিস্টেম /data/vendor ব্যবহার করা উচিত নয়।
system_executes_vendor_violators . সমস্ত সিস্টেম ডোমেনের জন্য অ্যাট্রিবিউট ( init এবং shell domains ব্যতীত) যা ভেন্ডর বাইনারিগুলি কার্যকর না করার প্রয়োজনীয়তা লঙ্ঘন করে। বিক্রেতা বাইনারিগুলির সম্পাদনে অস্থির API রয়েছে। প্ল্যাটফর্ম সরাসরি বিক্রেতা বাইনারি চালানো উচিত নয়। সুপারিশ:
- বিক্রেতা বাইনারিগুলির উপর এই ধরনের প্ল্যাটফর্ম নির্ভরতা অবশ্যই HIDL HAL-এর পিছনে থাকবে৷
  বা
- যে coredomains ভেন্ডর বাইনারিগুলিতে অ্যাক্সেসের প্রয়োজন সেগুলিকে vendor পার্টিশনে সরানো উচিত এবং এইভাবে, coredomain হওয়া বন্ধ করুন।

অবিশ্বস্ত বৈশিষ্ট্য

যে সমস্ত অবিশ্বস্ত অ্যাপগুলি স্বেচ্ছাচারী কোড হোস্ট করে তাদের HwBinder পরিষেবাগুলিতে অ্যাক্সেস থাকা উচিত নয়, এই ধরনের অ্যাপগুলি থেকে অ্যাক্সেসের জন্য যথেষ্ট নিরাপদ বলে বিবেচিত (নীচে নিরাপদ পরিষেবাগুলি দেখুন)। এর প্রধান দুটি কারণ হল:

HwBinder সার্ভারগুলি ক্লায়েন্ট প্রমাণীকরণ সম্পাদন করে না কারণ HIDL বর্তমানে কলার UID তথ্য প্রকাশ করে না। এমনকি HIDL এই ধরনের ডেটা প্রকাশ করলেও, অনেক HwBinder পরিষেবাগুলি হয় অ্যাপগুলির (যেমন, HALs) নীচের স্তরে কাজ করে বা অনুমোদনের জন্য অ্যাপ পরিচয়ের উপর নির্ভর করা উচিত নয়৷ এইভাবে, নিরাপদ থাকার জন্য, ডিফল্ট অনুমান হল যে প্রতিটি HwBinder পরিষেবা তার সমস্ত ক্লায়েন্টকে পরিষেবা দ্বারা প্রদত্ত ক্রিয়াকলাপগুলি সম্পাদন করার জন্য সমানভাবে অনুমোদিত হিসাবে বিবেচনা করে৷
HAL সার্ভারে (HwBinder পরিষেবাগুলির একটি উপসেট) system/core উপাদানগুলির তুলনায় নিরাপত্তা সংক্রান্ত সমস্যাগুলির উচ্চতর ঘটনা হার সহ কোড ধারণ করে এবং স্ট্যাকের নীচের স্তরগুলিতে অ্যাক্সেস রয়েছে (হার্ডওয়্যার পর্যন্ত) এইভাবে Android সুরক্ষা মডেলকে বাইপাস করার সুযোগ বৃদ্ধি করে৷

নিরাপদ সেবা

নিরাপদ সেবা অন্তর্ভুক্ত:

same_process_hwservice . এই পরিষেবাগুলি (সংজ্ঞা অনুসারে) ক্লায়েন্টের প্রক্রিয়ায় চলে এবং এইভাবে ক্লায়েন্ট ডোমেনের মতো একই অ্যাক্সেস রয়েছে যেখানে প্রক্রিয়াটি চলে।
coredomain_hwservice . এই পরিষেবাগুলি #2 কারণের সাথে যুক্ত ঝুঁকি তৈরি করে না।
hal_configstore_ISurfaceFlingerConfigs । এই পরিষেবাটি বিশেষভাবে যেকোন ডোমেনের ব্যবহারের জন্য ডিজাইন করা হয়েছে।
hal_graphics_allocator_hwservice . এই ক্রিয়াকলাপগুলি surfaceflinger বাইন্ডার পরিষেবা দ্বারাও অফার করা হয়, যেগুলি অ্যাপগুলিকে অ্যাক্সেস করার অনুমতি দেওয়া হয়৷
hal_omx_hwservice । এটি mediacodec বাইন্ডার পরিষেবার একটি HwBinder সংস্করণ, যা অ্যাপগুলিকে অ্যাক্সেস করার অনুমতি দেওয়া হয়েছে৷
hal_codec2_hwservice । এটি hal_omx_hwservice এর একটি নতুন সংস্করণ।

ব্যবহারযোগ্য গুণাবলী

নিরাপদ বলে বিবেচিত নয় এমন সমস্ত hwservices untrusted_app_visible_hwservice বৈশিষ্ট্য রয়েছে। সংশ্লিষ্ট HAL সার্ভারগুলিতে untrusted_app_visible_halserver বৈশিষ্ট্য রয়েছে। অ্যান্ড্রয়েড 9 এর সাথে লঞ্চ হওয়া ডিভাইসগুলি অবশ্যই untrusted অ্যাট্রিবিউট ব্যবহার করবে না৷

সুপারিশ:

অবিশ্বস্ত অ্যাপগুলির পরিবর্তে একটি সিস্টেম পরিষেবার সাথে কথা বলা উচিত যা বিক্রেতা HIDL HAL এর সাথে কথা বলে৷ উদাহরণস্বরূপ, অ্যাপগুলি binderservicedomain এর সাথে কথা বলতে পারে, তারপর mediaserver (যা একটি binderservicedomain ) hal_graphics_allocator এর সাথে কথা বলে।
বা
যে অ্যাপগুলির vendor HALগুলিতে সরাসরি অ্যাক্সেসের প্রয়োজন তাদের নিজস্ব বিক্রেতা-সংজ্ঞায়িত সেপলিসি ডোমেন থাকা উচিত৷

ফাইল বৈশিষ্ট্য পরীক্ষা

অ্যান্ড্রয়েড 9-এ বিল্ড টাইম পরীক্ষা রয়েছে যা নিশ্চিত করে যে নির্দিষ্ট অবস্থানের সমস্ত ফাইলের উপযুক্ত বৈশিষ্ট্য রয়েছে (যেমন, sysfs এর সমস্ত ফাইলের প্রয়োজনীয় sysfs_type বৈশিষ্ট্য রয়েছে)।

SELinux প্রসঙ্গ লেবেলিং

প্ল্যাটফর্ম এবং ভেন্ডর সেপলিসির মধ্যে পার্থক্যকে সমর্থন করার জন্য, সিস্টেম SELinux কনটেক্সট ফাইলগুলিকে আলাদা রাখার জন্য আলাদাভাবে তৈরি করে।

ফাইল প্রসঙ্গ

Android 8.0 file_contexts জন্য নিম্নলিখিত পরিবর্তনগুলি চালু করেছে:

বুট করার সময় ডিভাইসে অতিরিক্ত কম্পাইলেশন ওভারহেড এড়াতে, file_contexts বাইনারি ফর্মে থাকা বন্ধ করে দেয়। পরিবর্তে, তারা পঠনযোগ্য, রেগুলার এক্সপ্রেশন টেক্সট ফাইল যেমন {property, service}_contexts (যেমন সেগুলি পূর্ব-7.0 ছিল)।
file_contexts দুটি ফাইলের মধ্যে বিভক্ত:
- plat_file_contexts
  - অ্যান্ড্রয়েড প্ল্যাটফর্ম file_context যাতে কোনও ডিভাইস-নির্দিষ্ট লেবেল নেই, /vendor পার্টিশনের লেবেল করা অংশগুলি ছাড়া যা সেপলিসি ফাইলগুলির সঠিক কার্যকারিতা নিশ্চিত করার জন্য সুনির্দিষ্টভাবে লেবেল করা আবশ্যক।
  - ডিভাইসের /system/etc/selinux/plat_file_contexts এ system পার্টিশনে থাকতে হবে এবং বিক্রেতা file_context সাথে শুরুতে init দ্বারা লোড করতে হবে।
- vendor_file_contexts
  - ডিভাইসের Boardconfig.mk ফাইলগুলিতে BOARD_SEPOLICY_DIRS দ্বারা নির্দেশিত ডিরেক্টরিগুলিতে পাওয়া file_contexts একত্রিত করে তৈরি ডিভাইস-নির্দিষ্ট file_context ।
  - vendor পার্টিশনে অবশ্যই /vendor/etc/selinux/vendor_file_contexts এ ইনস্টল করতে হবে এবং প্ল্যাটফর্ম file_context সহ শুরুতে init দ্বারা লোড করতে হবে।

সম্পত্তি প্রসঙ্গ

অ্যান্ড্রয়েড 8.0-এ, property_contexts দুটি ফাইলের মধ্যে বিভক্ত:

plat_property_contexts
- Android প্ল্যাটফর্মের property_context যাতে কোনো ডিভাইস-নির্দিষ্ট লেবেল নেই।
- অবশ্যই /system/etc/selinux/plat_property_contexts এ system পার্টিশনে থাকতে হবে এবং vendor property_contexts সহ শুরুতে init দ্বারা লোড করতে হবে।
vendor_property_contexts
- ডিভাইসের Boardconfig.mk ফাইলগুলিতে BOARD_SEPOLICY_DIRS দ্বারা নির্দেশিত ডিরেক্টরিগুলিতে পাওয়া property_contexts একত্রিত করে ডিভাইস-নির্দিষ্ট property_context তৈরি করা হয়েছে।
- অবশ্যই /vendor/etc/selinux/vendor_property_contexts এ vendor পার্টিশনে থাকতে হবে এবং প্ল্যাটফর্মের property_context সহ শুরুতে init দ্বারা লোড করতে হবে

পরিষেবা প্রসঙ্গে

Android 8.0-এ, service_contexts নিম্নলিখিত ফাইলগুলির মধ্যে বিভক্ত:

plat_service_contexts
- servicemanager জন্য Android প্ল্যাটফর্ম-নির্দিষ্ট service_context । service_context এর কোনো ডিভাইস-নির্দিষ্ট লেবেল নেই।
- অবশ্যই /system/etc/selinux/plat_service_contexts এ system পার্টিশনে থাকতে হবে এবং বিক্রেতা service_contexts সাথে শুরুতে servicemanager দ্বারা লোড করতে হবে।
vendor_service_contexts
- ডিভাইসের Boardconfig.mk ফাইলগুলিতে BOARD_SEPOLICY_DIRS দ্বারা নির্দেশিত ডিরেক্টরিগুলিতে পাওয়া service_contexts একত্রিত করে তৈরি ডিভাইস-নির্দিষ্ট service_context ।
- অবশ্যই /vendor/etc/selinux/vendor_service_contexts এ vendor পার্টিশনে থাকতে হবে এবং প্ল্যাটফর্ম service_contexts সাথে শুরুতে servicemanager দ্বারা লোড করতে হবে।
- যদিও servicemanager বুট করার সময় এই ফাইলটি খোঁজেন, একটি সম্পূর্ণ সঙ্গতিপূর্ণ TREBLE ডিভাইসের জন্য, vendor_service_contexts অবশ্যই বিদ্যমান থাকবে না। এর কারণ হল vendor এবং system প্রক্রিয়াগুলির মধ্যে সমস্ত মিথস্ক্রিয়া অবশ্যই hwservicemanager / hwbinder মাধ্যমে যেতে হবে।
plat_hwservice_contexts
- hwservicemanager এর জন্য Android প্ল্যাটফর্ম hwservice_context যার কোনো ডিভাইস-নির্দিষ্ট লেবেল নেই।
- /system/etc/selinux/plat_hwservice_contexts এ system পার্টিশনে থাকতে হবে এবং শুরুতে vendor_hwservice_contexts সহ hwservicemanager দ্বারা লোড করা উচিত।
vendor_hwservice_contexts
- ডিভাইসের Boardconfig.mk ফাইলগুলিতে BOARD_SEPOLICY_DIRS দ্বারা নির্দেশিত ডিরেক্টরিগুলিতে পাওয়া hwservice_contexts একত্রিত করে ডিভাইস-নির্দিষ্ট hwservice_context তৈরি করা হয়েছে।
- অবশ্যই /vendor/etc/selinux/vendor_hwservice_contexts এ vendor পার্টিশনে থাকতে হবে এবং শুরুতে hwservicemanager দ্বারা plat_service_contexts সাথে লোড করতে হবে।
vndservice_contexts
- ডিভাইসের Boardconfig.mk এ BOARD_SEPOLICY_DIRS দ্বারা নির্দেশিত ডিরেক্টরিগুলিতে পাওয়া vndservice_contexts একত্রিত করে নির্মিত vndservicemanager এর জন্য ডিভাইস-নির্দিষ্ট service_context ।
- এই ফাইলটিকে অবশ্যই /vendor/etc/selinux/vndservice_contexts এ vendor পার্টিশনে থাকতে হবে এবং শুরুতে vndservicemanager দ্বারা লোড করতে হবে।

Seapp প্রসঙ্গ

অ্যান্ড্রয়েড 8.0-এ, seapp_contexts দুটি ফাইলের মধ্যে বিভক্ত:

plat_seapp_contexts
- অ্যান্ড্রয়েড প্ল্যাটফর্ম seapp_context যার কোনো ডিভাইস-নির্দিষ্ট পরিবর্তন নেই।
- /system/etc/selinux/plat_seapp_contexts. এ system পার্টিশনে থাকতে হবে।
vendor_seapp_contexts
- ডিভাইসের Boardconfig.mk ফাইলগুলিতে BOARD_SEPOLICY_DIRS দ্বারা নির্দেশিত ডিরেক্টরিগুলিতে পাওয়া seapp_contexts একত্রিত করে তৈরি প্ল্যাটফর্ম seapp_context এ ডিভাইস-নির্দিষ্ট এক্সটেনশন।
- /vendor/etc/selinux/vendor_seapp_contexts এ vendor পার্টিশনে থাকতে হবে।

MAC অনুমতি

Android 8.0-এ, mac_permissions.xml দুটি ফাইলের মধ্যে বিভক্ত:

প্ল্যাটফর্ম mac_permissions.xml
- অ্যান্ড্রয়েড প্ল্যাটফর্ম mac_permissions.xml যেটিতে কোনো ডিভাইস-নির্দিষ্ট পরিবর্তন নেই।
- /system/etc/selinux/. এ system পার্টিশনে থাকতে হবে।
নন-প্ল্যাটফর্ম mac_permissions.xml
- ডিভাইসের Boardconfig.mk ফাইলগুলিতে BOARD_SEPOLICY_DIRS দ্বারা নির্দেশিত ডিরেক্টরিগুলিতে পাওয়া mac_permissions.xml থেকে তৈরি প্ল্যাটফর্ম mac_permissions.xml এ ডিভাইস-নির্দিষ্ট এক্সটেনশন।
- /vendor/etc/selinux/. এ vendor পার্টিশনে থাকতে হবে।