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

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

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

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

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

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

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

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

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

ফাইল সংঘর্ষ প্রতিরোধ করা একটি কঠিন কাজ, কারণ প্ল্যাটফর্ম এবং ভেন্ডর পলিসি উভয়ই সাধারণত সমস্ত ফাইলসিস্টেমের জন্য লেবেল প্রদান করে। টাইপ নামকরণের মতো নয়, ফাইলের নেমস্পেসিং বাস্তবসম্মত নয়, যেহেতু এগুলোর বেশিরভাগই কার্নেল দ্বারা তৈরি হয়। এই সংঘর্ষগুলো প্রতিরোধ করতে, এই বিভাগে ফাইলসিস্টেমের নামকরণের নির্দেশিকা অনুসরণ করুন। অ্যান্ড্রয়েড ৮.০-এর জন্য, এগুলো প্রযুক্তিগতভাবে বাধ্যতামূলক নয়, বরং কেবলই সুপারিশ। ভবিষ্যতে, এই সুপারিশগুলো ভেন্ডর টেস্ট স্যুট (VTS) দ্বারা বাধ্যতামূলক করা হবে।

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

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

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

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

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

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

Procfs (/proc)

/proc এর ফাইলগুলোকে শুধুমাত্র genfscon লেবেল ব্যবহার করে চিহ্নিত করা যেতে পারে। অ্যান্ড্রয়েড ৭.০-তে, প্ল্যাটফর্ম এবং ভেন্ডর পলিসি উভয়ই procfs এর ফাইলগুলোকে চিহ্নিত করার জন্য genfscon ব্যবহার করত।

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

ডিবাগএফএস (/sys/kernel/debug)

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

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

ট্রেসএফএস (/sys/kernel/debug/tracing)

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

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

Sysfs (/sys)

/sys এর ফাইলগুলোকে file_contexts এবং genfscon উভয় ব্যবহার করে লেবেল করা যেতে পারে। অ্যান্ড্রয়েড ৭.০-তে, প্ল্যাটফর্ম এবং ভেন্ডর উভয়ই 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 এর অন্যান্য অংশ লেবেল করতে পারবে।

জেনফস লেবেল সংস্করণ

ভেন্ডর এপিআই লেভেল 202504 থেকে শুরু করে, 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 ফাইলে সংরক্ষিত থাকে।

উদাহরণ:

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

তবে, /sys/class/udc ডিফল্ট sysfs লেবেল অথবা ভেন্ডর-নির্দিষ্ট লেবেলসহ API লেভেল 202404 ব্যবহারকারী vendor পার্টিশনগুলো দ্বারা ব্যবহৃত হতে পারে। শর্তহীনভাবে /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 পলিসিকে প্রাইভেট এবং পাবলিক—এই দুই ভাগে ভাগ করা হয়। প্ল্যাটফর্ম-পাবলিক পলিসিতে এমন সব টাইপ এবং অ্যাট্রিবিউট থাকে যা ভেন্ডর এপিআই লেভেলের জন্য সবসময় উপলব্ধ থাকে এবং এটি প্ল্যাটফর্ম ও ভেন্ডরের মধ্যে একটি এপিআই হিসেবে কাজ করে। এই পলিসিটি ভেন্ডর পলিসি রাইটারদের কাছে উন্মুক্ত রাখা হয়, যাতে ভেন্ডররা ভেন্ডর পলিসি ফাইল তৈরি করতে পারে। এই ফাইলগুলো প্ল্যাটফর্ম-প্রাইভেট পলিসির সাথে একত্রিত হয়ে একটি ডিভাইসের জন্য সম্পূর্ণ কার্যকরী পলিসি তৈরি করে। প্ল্যাটফর্ম-পাবলিক পলিসিটি system/sepolicy/public এ সংজ্ঞায়িত করা থাকে।

উদাহরণস্বরূপ, vendor_init নামক একটি টাইপ, যা vendor-এর প্রেক্ষাপটে 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 ভেন্ডর পলিসি /sys/usb তে vendor_init অ্যাক্সেস মঞ্জুর করে। এই ক্ষেত্রে:

• ভেন্ডর পলিসি 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-এ আপগ্রেড করা হয়, তখন system/sepolicy/private/compat/202504/202504.cil এর অধীনে 202504 vendor পার্টিশনগুলির জন্য একটি নতুন ম্যাপিং ফাইল তৈরি করা হয়, যা 202604 বা তার পরবর্তী system পার্টিশনগুলির জন্য /system/etc/selinux/mapping/202504.cil এ ইনস্টল করা হয়। প্রাথমিকভাবে, এই ম্যাপিং ফাইলটিতে পূর্বে বর্ণিত আইডেন্টিটি ম্যাপিং থাকে। যদি 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 অধীনে তালিকাভুক্ত করতে হবে, যাতে এটি উল্লেখ করা যায় যে পূর্ববর্তী ভেন্ডর ভার্সনগুলিতে এর কোনো অনুরূপ টাইপ নেই।

প্ল্যাটফর্ম পলিসি, ভেন্ডর পলিসি এবং ম্যাপিং ফাইলের সমন্বয় ভেন্ডর পলিসি আপডেট না করেই সিস্টেমকে আপডেট করার সুযোগ দেয়। এছাড়াও, ভার্সনযুক্ত অ্যাট্রিবিউটগুলিতে রূপান্তর স্বয়ংক্রিয়ভাবে ঘটে, তাই ভেন্ডর পলিসিকে ভার্সনিংয়ের বিষয়টি নিয়ে ভাবতে হয় না এবং পাবলিক টাইপগুলো অপরিবর্তিতভাবে ব্যবহৃত হতে থাকে।

সিস্টেম_এক্সট পাবলিক এবং পণ্য পাবলিক নীতি

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

যখন 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 এ অপরিবর্তিত থাকে, তাহলে vendor পলিসি system_ext এবং product পার্টিশনগুলোর টাইপগুলোতে অ্যাক্সেস হারাতে পারে। এই সমস্যা এড়ানোর জন্য, system_ext এবং product পার্টিশনগুলোর উচিত কনক্রিট টাইপ থেকে type_ ver অ্যাট্রিবিউটে ম্যাপিং ফাইল সরবরাহ করা। প্রতিটি পার্টনার এই ম্যাপিং ফাইলগুলো রক্ষণাবেক্ষণের জন্য দায়ী থাকবে, যদি তারা ver vendor পার্টিশনের সাথে ver+1 (বা তার পরবর্তী) system_ext এবং product পার্টিশন সমর্থন করে।

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

1. ver system_ext এবং product পার্টিশন থেকে তৈরি হওয়া বেস ম্যাপিং ফাইলগুলো তাদের সোর্স ট্রি-তে কপি করুন।
2. প্রয়োজন অনুযায়ী ম্যাপিং ফাইলগুলো সংশোধন করুন।
3. ম্যাপিং ফাইলগুলো 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)

যদি 202604 system_ext এ bar_type যোগ করা হয়, এবং যদি 202504 vendor পার্টিশনের জন্য bar_type 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 পরিষেবাগুলিতে অ্যাক্সেস থাকা উচিত নয়, ব্যতিক্রম শুধু সেই পরিষেবাগুলি যা এই ধরনের অ্যাপ থেকে অ্যাক্সেসের জন্য যথেষ্ট নিরাপদ বলে বিবেচিত হয় (নীচে নিরাপদ পরিষেবাগুলি দেখুন)। এর দুটি প্রধান কারণ হলো:

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

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

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

• same_process_hwservice . এই সার্ভিসগুলো (সংজ্ঞা অনুসারে) ক্লায়েন্টের প্রসেসে চলে এবং তাই যে ক্লায়েন্ট ডোমেইনে প্রসেসটি চলে, সেই ডোমেইনের মতোই এদের অ্যাক্সেস থাকে।
• coredomain_hwservice . এই সার্ভিসগুলো ২ নং কারণের সাথে সম্পর্কিত কোনো ঝুঁকি তৈরি করে না।
• 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 অ্যাট্রিবিউট থাকে। অ্যান্ড্রয়েড ৯ দিয়ে চালু হওয়া ডিভাইসগুলোতে এই দুটি 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 পার্টিশনে /system/etc/selinux/plat_file_contexts এ থাকতে হবে এবং শুরুতে init দ্বারা vendor file_context সাথে লোড হতে হবে।
  • vendor_file_contexts
    • ডিভাইসের Boardconfig.mk ফাইলে BOARD_SEPOLICY_DIRS দ্বারা নির্দেশিত ডিরেক্টরিগুলোতে থাকা file_contexts একত্রিত করে ডিভাইস-নির্দিষ্ট file_context তৈরি করা হয়।
    • এটি অবশ্যই vendor পার্টিশনের /vendor/etc/selinux/vendor_file_contexts এ ইনস্টল করতে হবে এবং প্ল্যাটফর্ম file_context সাথে শুরুতে init দ্বারা লোড করতে হবে।

সম্পত্তির প্রেক্ষাপট

অ্যান্ড্রয়েড ৮.০-তে, property_contexts দুটি ফাইলে বিভক্ত করা হয়েছে:

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

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

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

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

Seapp প্রসঙ্গ

অ্যান্ড্রয়েড ৮.০-তে, seapp_contexts দুটি ফাইলে বিভক্ত করা হয়েছে:

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

MAC অনুমতি

অ্যান্ড্রয়েড ৮.০-তে, mac_permissions.xml ফাইলটি দুটি ভাগে বিভক্ত:

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

অ্যান্ড্রয়েড ১৭-এর জন্য শেয়ার্ড মেমোরিতে পরিবর্তন

অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, নিম্নলিখিত বৈশিষ্ট্য সহ চালু হওয়া ডিভাইসগুলিকে অবশ্যই memfd_class পলিসি ক্যাপাবিলিটি সক্রিয় করতে হবে এবং memfd_file ক্লাস অবজেক্ট সমর্থন করার জন্য তাদের শেয়ার্ড মেমরি সম্পর্কিত পলিসি আপডেট করতে হবে:

• ভেন্ডর এবং ওইএম-দের memfd সমর্থন করার জন্য তাদের ভেন্ডর পলিসি আপডেট করার সুযোগ দিতে ভেন্ডর এপিআই লেভেল ২০২৬০৪ বা তার চেয়ে উচ্চতর সংস্করণ প্রয়োজন। এটি বিদ্যমান ডিভাইসগুলোকে তাদের ভেন্ডর পার্টিশন আপডেট করার প্রয়োজন ছাড়াই অ্যান্ড্রয়েডের উচ্চতর সংস্করণে আপগ্রেড করার সুযোগ দেয়।
• android16-6.12 বা উচ্চতর কার্নেল, কারণ এই কার্নেলগুলো memfd_class ফিচারটি সমর্থন করে, যা memfd জন্য সূক্ষ্ম-স্তরের পলিসি বাস্তবায়নের জন্য প্রয়োজন।

memfd_class পলিসি সক্ষমতা সক্রিয় করুন

সম্প্রতি পর্যন্ত, SELinux একটি memfd তার সহায়ক ফাইলসিস্টেম—tmpfs-এর মতোই একই ধরনের ফাইল হিসেবে চিহ্নিত করত। এর ফলে, পলিসির দৃষ্টিকোণ থেকে একটি tmpfs মাউন্টে থাকা অন্য কোনো ফাইল থেকে একটি memfd আলাদা করা অসম্ভব ছিল। এখন, SELinux একটি memfd বরাদ্দকারী প্রসেসের সিকিউরিটি কনটেক্সট দিয়ে চিহ্নিত করে এবং memfds memfd_file ক্লাস অবজেক্ট হিসেবে গণ্য করা হয়। পুরোনো ইউজারস্পেস এনভায়রনমেন্টের সাথে ব্যাকওয়ার্ড কম্প্যাটিবিলিটি বজায় রাখার জন্য এই কার্যকারিতাটি memfd_class পলিসি ক্যাপাবিলিটি দ্বারা সুরক্ষিত।

memfd_class পলিসি ক্যাপাবিলিটি সক্রিয় করতে, BOARD_VENDOR_SEPOLICY_DIRS এর অধীনে একটি policy_capabilities ফাইল তৈরি করুন। ফাইলটিতে নিম্নলিখিত এন্ট্রিটি থাকতে হবে:

# $BOARD_VENDOR_SEPOLICY_DIRS/*/policy_capabilities
policycap memfd_class;

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

memfd_class পলিসি ক্যাপাবিলিটি সক্রিয় আছে কিনা তা যাচাই করুন।

memfd_class পলিসি ক্যাপাবিলিটির স্ট্যাটাস চেক করতে নিম্নলিখিত কমান্ডটি ব্যবহার করুন:

adb shell 'cat /sys/fs/selinux/policy_capabilities/memfd_class'

ফলাফল 1 হলে, memfd_class পলিসি ক্যাপাবিলিটিটি সক্রিয় থাকে। অন্যথায়, এটি সক্রিয় থাকে না।

বিদ্যমান নীতি memfd-তে স্থানান্তর করুন

কিছু প্রসেস তাদের memfds অ্যাক্সেস ও নেমস্পেস করার জন্য নিজেদের পলিসিতে tmpfs_domain() ম্যাক্রো ব্যবহার করত, উদাহরণস্বরূপ:

# foo.te
tmpfs_domain(foo)

এর অনুবাদ হলো:

# foo.te
type_transition foo tmpfs:file foo_tmpfs;
allow foo foo_tmpfs:file { read write getattr map };

এবং আসুন প্রসেস bar প্রসেস foo -এর memfds এভাবে অ্যাক্সেস করে:

# bar.te
allow bar foo_tmpfs:file { read write getattr map };

memfd_class পলিসি ক্যাপাবিলিটি সক্রিয় করা থাকলে, tmpfs_domain() ম্যাক্রোটির আর প্রয়োজন নেই, কারণ প্ল্যাটফর্ম পলিসি আপডেট করা হয়েছে যাতে যেকোনো প্রসেস তার নিজস্ব memfds তৈরি ও ব্যবহার করতে পারে, যেমনটি এখানে দেখা যাচ্ছে:

# system/sepolicy/private/domain.te
allow domain self:memfd_file { create read write getattr map };

এবং foo প্রসেস দ্বারা তৈরি memfds bar প্রসেস এইভাবে অ্যাক্সেস করতে পারে:

# bar.te
allow bar foo:memfd_file { read write getattr map };

memfd এর বিদ্যমান ব্যবহারগুলো অন্তর্ভুক্ত করার জন্য প্ল্যাটফর্মের পলিসি আপডেট করা হয়েছে। তবে, tmpfs লেবেল ব্যবহারকারী ভেন্ডর এবং ডিভাইস-নির্দিষ্ট পলিসি অবশ্যই memfd_file ব্যবহার করার জন্য আপডেট করতে হবে। যদি পলিসিটি এমন SoC বা ডিভাইসগুলোর মধ্যে শেয়ার করা হয় যেগুলোর ভেন্ডর API লেভেল 202604 বা তার চেয়ে উচ্চতর নয়, তাহলে সামঞ্জস্য রক্ষার জন্য নতুন memfd_file পলিসির পাশাপাশি পুরোনো tmpfs পলিসিটিও বহাল রাখার পরামর্শ দেওয়া হচ্ছে।

memfd সম্পর্কিত AVC প্রত্যাখ্যানগুলি সনাক্ত করুন

নিম্নলিখিত কমান্ডটি ব্যবহার করে Memfd সম্পর্কিত অস্বীকৃতিগুলো পুনরুদ্ধার করা যেতে পারে:

adb shell logcat -d -b events | grep memfd

tmpfs কে লক্ষ্য করে avc প্রত্যাখ্যান

নিম্নলিখিত উদাহরণটি এমন একটি avc ডিনায়াল দেখায় যা এমন একটি প্রসেসের ক্ষেত্রে ঘটেছিল যেটি এমন একটি memfd তে লেখার চেষ্টা করেছিল যেখানে তার লেখার অনুমতি ছিল না:

audit(0.0:539): avc:  denied  { write } for  comm="binder:665_1" name="memfd:MessageQueue"
dev="tmpfs" ino=8324 scontext=u:r:mediacodec:s0 tcontext=u:object_r:tmpfs:s0 tclass=file
permissive=0

যখন memfd_class পলিসি ক্যাপাবিলিটি সক্রিয় করা থাকে, তখন একটি memfd এর টার্গেট কনটেক্সট হয় অ্যালোকেটকারী প্রসেসের সিকিউরিটি কনটেক্সট, tmpfs নয়, এবং টার্গেট ক্লাস হয় memfd_file , file নয়। অতএব, যদি আপনি memfd সম্পর্কিত avc ডিনায়াল লক্ষ্য করেন, যেখানে প্রশ্নবিদ্ধ memfd টিকে একটি tmpfs ফাইল হিসাবে লেবেল করা হয়েছে, তাহলে memfd_class পলিসি ক্যাপাবিলিটি সক্রিয় করা নেই।

memfd_file কে টার্গেট ক্লাস হিসেবে ব্যবহার করলে avc প্রত্যাখ্যান হয়।

নিম্নলিখিত উদাহরণটি একটি avc ডিনায়াল দেখায় যা এমন একটি প্রসেসের ক্ষেত্রে ঘটেছিল যেটি এমন একটি memfd তে লেখার চেষ্টা করছিল যেখানে তার লেখার অনুমতি ছিল না, এবং memfd_class পলিসি ক্যাপাবিলিটি সক্রিয় ছিল। এছাড়াও, ডিনায়ালের পরে logd দ্বারা নির্গত একই টাইমস্ট্যাম্পের একটি অতিরিক্ত লাইনও দেখানো হয়েছে:

audit(0.0:86): avc: denied { read } for
path=2F6D656D66643A4D6564696142756666657247726F7570202864656C6574656429 ino=512 dev=""
scontext=u:r:mediaserver:s0 tcontext=u:object_r:mediaextractor:s0 tclass=memfd_file

auditd  : Decoded path for audit(0.0:86): /memfd:MediaBufferGroup (deleted)

মিলে যাওয়া টাইমস্ট্যাম্পটি নির্দেশ করে যে ‘ Decoded path for … log 0.0.86 টাইমস্ট্যাম্পযুক্ত avc ডিনায়ালের সাথে সম্পর্কিত। এই লগটি avc ডিনায়ালের পাথ ভ্যালু থেকে হেক্সাডেসিমাল স্ট্রিংটি ডিকোড করে এবং memfd মেমরি রিজিয়নের নাম প্রদান করে, যা কোন বাফার শেয়ার করা হচ্ছে তা বুঝতে সহায়ক হতে পারে। কোন প্রসেসগুলোর মেমরি শেয়ার করার প্রয়োজন, তা বোঝার জন্য সোর্স কনটেক্সট এবং টার্গেট কনটেক্সট সহায়ক। পূর্ববর্তী উদাহরণ থেকে এটা স্পষ্ট যে mediaserver প্রসেসটির mediaextractor এর memfds অ্যাক্সেস করার প্রয়োজন আছে। অতএব, উপযুক্ত পলিসিটি হলো:

# mediaserver.te
allow mediaserver mediaextractor:memfd_file { getattr read write map };

অ্যান্ড্রয়েড ১৭-এ নিরাপত্তা ডোমেইন আপডেট

অ্যান্ড্রয়েড ১৭-এর ASharedMemory_create() এপিআই শেয়ার্ড মেমোরি বরাদ্দের জন্য লিগ্যাসি ashmem ড্রাইভার এবং memfd ফ্রেমওয়ার্কের মধ্যে যেকোনো একটিকে বেছে নিতে শর্তসাপেক্ষ লজিক প্রয়োগ করে।

যেসব ডিভাইস memfd শর্ত পূরণ করে (ভেন্ডর এপিআই লেভেল 202604 বা তার বেশি এবং কার্নেল android16-6.12 বা নতুন), সেগুলোর ক্ষেত্রে এপিআই কলিং অ্যাপের targetSdkVersion মূল্যায়ন করে। যদি টার্গেট এসডিকে ভার্সন 37 বা তার বেশি হয়, তাহলে একটি memfd বরাদ্দ করা হয়। এর ফলে ডেভেলপাররা তাদের টার্গেট এসডিকে ভার্সন আপগ্রেড করার সময় যেসব সমস্যার সম্মুখীন হন, সেগুলো সমাধান করতে পারেন।

যদি ডিভাইসটি memfd's পূর্বশর্তগুলো পূরণ না করে, তাহলে ASharedMemory ashmem-এ ফিরে যায়। এর ফলে পুরোনো ভেন্ডর পার্টিশন বা কার্নেলযুক্ত আপগ্রেড করা ডিভাইসগুলোর সাথে সামঞ্জস্যতা বজায় থাকে।

এই পরিবর্তনটি কার্যকর করার জন্য, প্ল্যাটফর্ম SELinux পলিসি platform_app , priv_app , এবং untrusted_app সিকিউরিটি ডোমেইনে থাকা SDK ভার্সন ৩৭ বা তার উচ্চতর সংস্করণকে টার্গেট করা অ্যাপগুলোকে /dev/ashmem খুলতে এবং memfd তে ashmem ioctl কমান্ড চালাতে বাধা দেয়। টার্গেট SDK ভার্সনের উপর ভিত্তি করে ঐ অ্যাপ ডোমেইনগুলোকে বিভক্ত করার মাধ্যমে এটি সম্পন্ন করা হয়। এর ফলে platform_app_36 , priv_app_36 , এবং untrusted_app_34 সিকিউরিটি ডোমেইনগুলো চালু হয়, যেগুলো অন্যান্য অ্যাপ ডোমেইনের মতোই ashmem খোলার অনুমতি এবং memfds তে ashmem ioctl কমান্ড চালানোর ক্ষমতা ধরে রাখে।

ভবিষ্যতের কোনো অ্যান্ড্রয়েড রিলিজে, ashmem ডিভাইস খোলার এবং memfds তে ashmem ioctl কমান্ড চালানোর অনুমতি থাকা অ্যাপের সংখ্যা কমিয়ে শুধু platform_app_36 , priv_app_36 , এবং পুরোনো SDK সংস্করণগুলোর জন্য untrusted_app_34 ও untrusted অ্যাপ ডোমেইনে সীমাবদ্ধ করা হবে।

যেসব অ্যাপ তাদের টার্গেট SDK ভার্সন পিন করে রাখে, তাদের জন্য কাস্টম ভেন্ডর বা OEM SELinux পলিসিগুলোকে অবশ্যই এই ডোমেইন পরিবর্তনগুলোর সাথে সামঞ্জস্য রেখে আপডেট করতে হবে, যেমনটি নিম্নলিখিত বিভাগগুলোতে বিস্তারিতভাবে বর্ণনা করা হয়েছে।

প্ল্যাটফর্ম_অ্যাপ SELinux ডোমেইন আপডেট

অ্যাপের targetSdkVersion এর উপর ভিত্তি করে platform_app ডোমেইনটি বিভক্ত করা হয়। যে প্ল্যাটফর্ম অ্যাপগুলো SDK ভার্সন ৩৭ বা তার বেশি টার্গেট করে, সেগুলোকে platform_app ডোমেইন দেওয়া হয়, আর যেগুলো SDK ভার্সন ৩৬ বা তার কম টার্গেট করে, সেগুলো platform_app_36 ব্যবহার করে। ব্যাকওয়ার্ড কম্প্যাটিবিলিটির জন্য platform_app_36 ডোমেইনটি /dev/ashmem খোলার ক্ষমতা ধরে রাখে। উভয় ডোমেইনে পলিসি ম্যানেজমেন্ট সহজ করার জন্য platform_app_all অ্যাট্রিবিউটটি ব্যবহার করুন।

এমন একটি পরিস্থিতি বিবেচনা করুন যেখানে প্ল্যাটফর্ম অ্যাপ sample-plat-app /dev/foo_device থেকে ডেটা পড়তে ও লিখতে হবে। বিদ্যমান ভেন্ডর SELinux পলিসিটি দেখতে এইরকম হতে পারে:

# This will only allow sample-plat-app to access the device if it
# is placed in the platform_app domain (i.e. target SDK version is 37 or higher).
allow platform_app foo_device:chr_file rw_file_perms;

তবে, যদি sample-plat-app টার্গেট SDK ভার্সন ৩৬-এ পিন করা থাকে, তাহলে এটিকে platform_app_36 ডোমেইনে রাখা হয়, এবং আগের SELinux পলিসিটি প্রয়োগ হয় না, এবং নিম্নলিখিত AVC ডিনায়ালটি পরিলক্ষিত হয়:

auditd  : type=1400 audit(0.0:11): avc:  denied  { read write } for  comm="sample-plat-app" path="/dev/foo_device" dev="tmpfs" ino=1609 scontext=u:r:platform_app_36:s0:c512,c768 tcontext=u:object_r:foo_device:s0 tclass=chr_file permissive=0

এর সমাধান করতে, পলিসিটি এভাবে আপডেট করা যেতে পারে, যেহেতু অ্যাপটির ডিভাইস নোডে সবসময় অ্যাক্সেস থাকা উচিত:

# This allows sample-plat-app to access the device independent of
# target SDK version.
allow platform_app_all foo_device:chr_file rw_file_perms;

এমন পরিস্থিতি দেখা দিতে পারে যেখানে platform_app_all কাজ নাও করতে পারে। উদাহরণস্বরূপ, যদি platform_app_all সাথে hal_client_domain() ম্যাক্রো ব্যবহার করা হয়, তাহলে পলিসিটি কম্পাইল হতে ব্যর্থ হয়। এর কারণ হলো platform_app_all একটি অ্যাট্রিবিউট, এবং hal_client_domain() এর সাথে আরেকটি অ্যাট্রিবিউট সংযুক্ত করার চেষ্টা করে, যা সম্ভব নয়।

# platform_app.te
hal_client_domain(platform_app, hal_foo)

সেই পরিস্থিতিগুলিতে, সরাসরি platform_app_36 টাইপটি ব্যবহার করা প্রয়োজন, তাই আপনার পলিসিতে নিম্নলিখিত বিষয়বস্তু রয়েছে:

# platform_app.te
hal_client_domain(platform_app, hal_foo)

# platform_app_36.te
hal_client_domain(platform_app_36, hal_foo)

priv_app SELinux ডোমেইন আপডেট

অ্যাপের targetSdkVersion এর উপর ভিত্তি করে priv_app ডোমেইনটি বিভক্ত করা হয়। যেসব প্রিভিলেজড অ্যাপ SDK ভার্সন ৩৭ বা তার বেশি টার্গেট করে, তাদের priv_app ডোমেইনটি দেওয়া হয়, আর যেসব অ্যাপ SDK ভার্সন ৩৬ বা তার কম টার্গেট করে, তারা priv_app_36 ব্যবহার করে। ব্যাকওয়ার্ড কম্প্যাটিবিলিটির জন্য priv_app_36 ডোমেইনটি /dev/ashmem খোলার ক্ষমতা ধরে রাখে। উভয় ডোমেইনে পলিসি ম্যানেজমেন্ট সহজ করার জন্য priv_app_all অ্যাট্রিবিউটটি ব্যবহার করুন।

এমন একটি পরিস্থিতি বিবেচনা করুন যেখানে প্ল্যাটফর্ম অ্যাপ sample-priv-app /dev/foo_device থেকে ডেটা পড়তে ও লিখতে হবে। বিদ্যমান ভেন্ডর SELinux পলিসিটি দেখতে এইরকম হতে পারে:

# This will only allow sample-priv-app to access the device if it
# is placed in the priv_app domain (i.e. target SDK version is 37 or higher).
allow priv_app foo_device:chr_file rw_file_perms;

তবে, যদি sample-priv-app টার্গেট SDK ভার্সন ৩৬-এ পিন করা থাকে, তাহলে এটিকে priv_app_36 ডোমেইনে রাখা হয়, এবং আগের SELinux পলিসিটি প্রয়োগ হয় না, এবং নিম্নলিখিত AVC ডিনায়ালটি পরিলক্ষিত হয়:

auditd  : type=1400 audit(0.0:11): avc:  denied  { read write } for  comm="sample-priv-app" path="/dev/foo_device" dev="tmpfs" ino=1609 scontext=u:r:priv_app_36:s0:c512,c768 tcontext=u:object_r:foo_device:s0 tclass=chr_file permissive=0

এর সমাধান করতে, পলিসিটি এভাবে আপডেট করা যেতে পারে, যেহেতু অ্যাপটির ডিভাইস নোডে সবসময় অ্যাক্সেস থাকা উচিত:

# This allows sample-priv-app to access the device independent of
# target SDK version.
allow priv_app_all foo_device:chr_file rw_file_perms;

এমন পরিস্থিতি দেখা দিতে পারে যেখানে priv_app_all কাজ নাও করতে পারে। উদাহরণস্বরূপ, যদি priv_app_all সাথে hal_client_domain() ম্যাক্রো ব্যবহার করা হয়, তাহলে পলিসিটি কম্পাইল হতে ব্যর্থ হবে। এর কারণ হলো priv_app_all একটি অ্যাট্রিবিউট, এবং hal_client_domain() এর সাথে আরেকটি অ্যাট্রিবিউট সংযুক্ত করার চেষ্টা করবে, যা সম্ভব নয়।

# priv_app.te
hal_client_domain(priv_app, hal_foo)

In those scenarios, it is required to use the priv_app_36 type directly, so your policy files will look something like this:

# priv_app.te
hal_client_domain(priv_app, hal_foo)

# priv_app_36.te
hal_client_domain(priv_app_36, hal_foo)

untrusted_app SELinux domain updates

The untrusted_app domain is split based on the app's targetSdkVersion . Untrusted apps targeting SDK 37 version or higher are assigned the untrusted_app domain, while those targeting SDK versions 34-36 inclusive are assigned the new untrusted_app_34 domain. The untrusted_app_34 domain, as well as the untrusted_app_X domains, where `X` is an older target SDK version, retain the ability to open `/dev/ashmem` for backward compatibility.