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

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

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

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

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

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

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

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

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

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

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

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

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

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

প্রকফস (/প্রক)

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

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

ডিবাগ (/sys/কার্নেল/ডিবাগ)

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

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

ট্রেসএফএস (/sys/কার্নেল/ডিবাগ/ট্রেসিং)

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

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

সিসফস (/সিস)

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

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

tmpfs (/dev)

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

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

রুটএফএস (/)

/ -এ থাকা ফাইলগুলিকে file_contexts এ লেবেল করা যেতে পারে। অ্যান্ড্রয়েড ৭.০-তে, প্ল্যাটফর্ম এবং বিক্রেতা উভয়ই এখানে ফাইল লেবেল করে।

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

তথ্য (/তথ্য)

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

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

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

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

উদাহরণ:

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

তবে, /sys/class/udc API লেভেল 202404 ব্যবহার করে vendor পার্টিশন দ্বারা ব্যবহৃত হতে পারে, হয় ডিফল্ট sysfs লেবেল অথবা বিক্রেতা-নির্দিষ্ট লেবেল সহ। শর্তহীনভাবে /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

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

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

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

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

বিক্রেতা নীতিতে একটি নিয়ম allow vendor_init sysfs:chr_file rw_file_perms; লেখা হয়, কারণ /sys/usb 202504 প্ল্যাটফর্ম নীতিতে 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 এ বাম্প করা হয়, system/sepolicy/private/compat/202504/202504.cil অধীনে 202504 vendor পার্টিশনের জন্য একটি নতুন ম্যাপিং ফাইল তৈরি করা হয়, যা 202604 বা নতুন system পার্টিশনের জন্য /system/etc/selinux/mapping/202504.cil এ ইনস্টল করা হয়। প্রাথমিকভাবে, এই ম্যাপিং ফাইলটিতে পূর্বে বর্ণিত হিসাবে পরিচয় ম্যাপিং থাকে। যদি 202604 প্ল্যাটফর্ম নীতিতে /sys/usb এর জন্য একটি নতুন লেবেল sysfs_usb যোগ করা হয়, তাহলে ম্যাপিং ফাইলটি map sysfs_202504 to 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 পাবলিক এবং প্রোডাক্ট পাবলিক পলিসি

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

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

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

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

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

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 পরিষেবা হয় অ্যাপের (যেমন, HAL) স্তরের নীচে কাজ করে অথবা অনুমোদনের জন্য অ্যাপ পরিচয়ের উপর নির্ভর করতে হয় না। অতএব, নিরাপদ থাকার জন্য, ডিফল্ট অনুমান হল যে প্রতিটি HwBinder পরিষেবা তার সমস্ত ক্লায়েন্টকে পরিষেবা দ্বারা প্রদত্ত ক্রিয়াকলাপ সম্পাদনের জন্য সমানভাবে অনুমোদিত হিসাবে বিবেচনা করে।
HAL সার্ভারগুলিতে (HwBinder পরিষেবার একটি উপসেট) system/core উপাদানগুলির তুলনায় নিরাপত্তা সমস্যার উচ্চতর হারের কোড থাকে এবং স্ট্যাকের নীচের স্তরগুলিতে (হার্ডওয়্যার পর্যন্ত) অ্যাক্সেস থাকে, ফলে অ্যান্ড্রয়েড সুরক্ষা মডেলকে বাইপাস করার সুযোগ বৃদ্ধি পায়।

নিরাপদ পরিষেবা

নিরাপদ পরিষেবাগুলির মধ্যে রয়েছে:

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

ব্যবহারযোগ্য বৈশিষ্ট্য

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

সুপারিশ:

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

ফাইল অ্যাট্রিবিউট পরীক্ষা

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

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

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

ফাইলের প্রসঙ্গ

অ্যান্ড্রয়েড ৮.০ file_contexts জন্য নিম্নলিখিত পরিবর্তনগুলি চালু করেছে:

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

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

অ্যান্ড্রয়েড ৮.০-এ, 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 পার্টিশনে থাকা আবশ্যক এবং শুরুতে init দ্বারা প্ল্যাটফর্ম property_context সহ লোড করা আবশ্যক।

পরিষেবার প্রেক্ষাপট

অ্যান্ড্রয়েড ৮.০-এ, service_contexts নিম্নলিখিত ফাইলগুলির মধ্যে বিভক্ত:

plat_service_contexts
- servicemanager এর জন্য Android প্ল্যাটফর্ম-নির্দিষ্ট service_context । service_context কোনও ডিভাইস-নির্দিষ্ট লেবেল নেই।
- /system/etc/selinux/plat_service_contexts এ system পার্টিশনে থাকা আবশ্যক এবং শুরুতে servicemanager দ্বারা বিক্রেতার service_contexts সহ লোড করা উচিত।
vendor_service_contexts
- ডিভাইসের Boardconfig.mk ফাইলগুলিতে BOARD_SEPOLICY_DIRS দ্বারা নির্দেশিত ডিরেক্টরিগুলিতে পাওয়া service_contexts একত্রিত করে ডিভাইস-নির্দিষ্ট service_context তৈরি করা হয়েছে।
- /vendor/etc/selinux/vendor_service_contexts এ vendor পার্টিশনে থাকা আবশ্যক এবং শুরুতে servicemanager দ্বারা প্ল্যাটফর্ম service_contexts সাথে লোড করা উচিত।
- যদিও 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
- ডিভাইস-নির্দিষ্ট hwservice_context ডিভাইসের Boardconfig.mk ফাইলগুলিতে BOARD_SEPOLICY_DIRS দ্বারা নির্দেশিত ডিরেক্টরিগুলিতে পাওয়া hwservice_contexts একত্রিত করে তৈরি করা হয়েছে।
- /vendor/etc/selinux/vendor_hwservice_contexts এ vendor পার্টিশনে থাকা আবশ্যক এবং শুরুতে plat_service_contexts সহ hwservicemanager দ্বারা লোড করা উচিত।
vndservice_contexts
- ডিভাইসের Boardconfig.mk এ BOARD_SEPOLICY_DIRS দ্বারা নির্দেশিত ডিরেক্টরিগুলিতে পাওয়া vndservice_contexts একত্রিত করে তৈরি vndservicemanager এর জন্য ডিভাইস-নির্দিষ্ট service_context ।
- এই ফাইলটি /vendor/etc/selinux/vndservice_contexts এ vendor পার্টিশনে থাকা আবশ্যক এবং শুরুতে vndservicemanager দ্বারা লোড করা উচিত।

সিপ প্রসঙ্গ

অ্যান্ড্রয়েড ৮.০-এ, 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_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 পার্টিশনে থাকা আবশ্যক।