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

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

এই নিবন্ধটি বর্ণনা করে যে Android কীভাবে প্ল্যাটফর্ম OTA-এর সাথে নীতি সামঞ্জস্যপূর্ণ সমস্যাগুলি পরিচালনা করে, যেখানে নতুন প্ল্যাটফর্ম SELinux সেটিংস পুরানো বিক্রেতা SELinux সেটিংস থেকে আলাদা হতে পারে।

ট্রেবল-ভিত্তিক SELinux নীতি নকশা প্ল্যাটফর্ম এবং বিক্রেতা নীতির মধ্যে একটি বাইনারি পার্থক্য বিবেচনা করে; স্কিমটি আরও জটিল হয়ে ওঠে যদি ভেন্ডর পার্টিশন নির্ভরতা তৈরি করে, যেমন platform < vendor < oem ।

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

সংস্করণের জন্য, রপ্তানি করা প্ল্যাটফর্ম-পাবলিক নীতি বৈশিষ্ট্য হিসাবে লেখা হবে।
নীতি লেখার সহজতার জন্য, রপ্তানি করা প্রকারগুলিকে নীতি তৈরির প্রক্রিয়ার অংশ হিসাবে সংস্করণযুক্ত বৈশিষ্ট্যে রূপান্তরিত করা হবে। সর্বজনীন প্রকারগুলি বিক্রেতা প্রসঙ্গ ফাইলগুলির দ্বারা প্রদত্ত লেবেলিং সিদ্ধান্তগুলিতে সরাসরি ব্যবহার করা যেতে পারে।

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

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

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

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

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

লেবেল সংঘর্ষের পাশাপাশি, SELinux প্রকার/অ্যাট্রিবিউটের নামগুলিও সংঘর্ষ হতে পারে। একটি টাইপ/অ্যাট্রিবিউট নামের সংঘর্ষের ফলে সর্বদা একটি নীতি কম্পাইলার ত্রুটি দেখা দেয়।

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

SELinux একই ধরনের/অ্যাট্রিবিউটের একাধিক ঘোষণা অনুমোদন করে না। ডুপ্লিকেট ঘোষণা সহ নীতি সংকলন ব্যর্থ হবে. টাইপ এবং অ্যাট্রিবিউট নামের সংঘর্ষ এড়াতে, সমস্ত বিক্রেতার ঘোষণা vendor_ দিয়ে শুরু করে নামস্থানে রাখা উচিত।

type foo, domain; → type vendor_foo, domain;

সিস্টেম সম্পত্তি এবং প্রক্রিয়া লেবেল মালিকানা

সম্পত্তির নামস্থান ব্যবহার করে লেবেলিং সংঘর্ষ এড়ানো সবচেয়ে ভালো সমাধান করা হয়। প্ল্যাটফর্ম বৈশিষ্ট্যগুলি সহজেই সনাক্ত করতে এবং এক্সপোর্ট-প্ল্যাটফর্ম বৈশিষ্ট্যগুলির নাম পরিবর্তন বা যোগ করার সময় নামের দ্বন্দ্ব এড়াতে, সমস্ত বিক্রেতার বৈশিষ্ট্যগুলির নিজস্ব উপসর্গ রয়েছে তা নিশ্চিত করুন:

সম্পত্তির ধরন	গ্রহণযোগ্য উপসর্গ
নিয়ন্ত্রণ বৈশিষ্ট্য	`ctl.vendor.` `ctl.start$vendor.` `ctl.stop$vendor.` `init.svc.vendor.`
পঠনযোগ্য	`vendor.`
শুধুমাত্র পঠনযোগ্য	`ro.vendor.` `ro.boot.` `ro.hardware.`
অবিরাম	`persist.vendor.`

বিক্রেতারা ro.boot.* (যা কার্নেল cmdline থেকে আসে) এবং ro.hardware.* (একটি স্পষ্ট হার্ডওয়্যার-সম্পর্কিত সম্পত্তি) ব্যবহার করা চালিয়ে যেতে পারে।

init rc ফাইলের সমস্ত বিক্রেতা পরিষেবাগুলিতে vendor. অ-সিস্টেম পার্টিশনের init rc ফাইলের পরিষেবাগুলির জন্য। বিক্রেতা বৈশিষ্ট্যগুলির জন্য SELinux লেবেলে অনুরূপ নিয়ম প্রয়োগ করা হয় ( বিক্রেতা বৈশিষ্ট্যের জন্য vendor_ )।

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

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

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

শুধুমাত্র সিস্টেম ইমেজ অবশ্যই /system /system জন্য file_contexts , service_contexts , ইত্যাদির মাধ্যমে লেবেল প্রদান করবে /vendor

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

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

`/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 । যদি vendor প্রক্রিয়াগুলির /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 লেবেল পুরানো ভেন্ডর পার্টিশনের জন্য ঐচ্ছিক। এটি পুরানো বিক্রেতা পার্টিশনগুলিকে তাদের বিদ্যমান এসইপলিসি বাস্তবায়ন রাখতে দেয়। এটি মেকফাইল ভেরিয়েবল 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 ব্যবহার করে ভেন্ডর পার্টিশন দ্বারা /sys/class/udc ব্যবহার করা হতে পারে। শর্তহীনভাবে /sys/class/udc হিসাবে sysfs_udc লেবেল করা এই ভেন্ডর পার্টিশনগুলির সাথে সামঞ্জস্য নষ্ট করতে পারে। BOARD_GENFS_LABELS_VERSION চেক করে, প্ল্যাটফর্মটি পুরানো বিক্রেতা পার্টিশনগুলির জন্য পূর্ববর্তী লেবেল এবং অনুমতিগুলি ব্যবহার করে চলেছে৷

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

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

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

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

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

নীতিটি বেশিরভাগ বিদ্যমান প্রকারের পরিপ্রেক্ষিতে লেখা হয়:

allow source_type target_type:target_class permission(s);

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

File_contexts:
/sys/A   u:object_r:sysfs:s0
Platform: allow p_domain sysfs:class perm;
Vendor: allow v_domain sysfs:class perm;

এতে পরিবর্তন করা যেতে পারে:

File_contexts:
/sys/A   u:object_r:sysfs_A:s0

যদিও বিক্রেতা নীতি একই থাকবে, নতুন sysfs_A ধরনের নীতির অভাবের কারণে v_domain অ্যাক্সেস হারাবে।

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

ভার্সনড অ্যাট্রিবিউট হিসেবে পাবলিক পলিসিকে সংজ্ঞায়িত করা দুটি নীতির সামঞ্জস্যের লক্ষ্য পূরণ করে:

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

নীতি লিখনযোগ্যতা

নীতি বিকাশের জন্য নির্দিষ্ট সংস্করণ পরিবর্তনের জ্ঞানের প্রয়োজন না করার লক্ষ্য পূরণ করতে, Android 8.0 প্ল্যাটফর্ম-পাবলিক নীতির ধরন এবং তাদের বৈশিষ্ট্যগুলির মধ্যে একটি ম্যাপিং অন্তর্ভুক্ত করে। foo টাইপ foo_v N অ্যাট্রিবিউটে ম্যাপ করা হয়েছে, যেখানে N হল টার্গেট করা সংস্করণ। vN PLATFORM_SEPOLICY_VERSION বিল্ড ভেরিয়েবলের সাথে মিলে যায় এবং এটি MM.NN ফর্মের, যেখানে MM প্ল্যাটফর্ম SDK নম্বরের সাথে মিলে যায় এবং NN হল একটি প্ল্যাটফর্ম সেপলিসি নির্দিষ্ট সংস্করণ।

পাবলিক পলিসিতে অ্যাট্রিবিউটগুলি ভার্সন করা হয় না, বরং একটি API হিসাবে বিদ্যমান থাকে যার উপর প্ল্যাটফর্ম এবং ভেন্ডর পলিসি দুটি পার্টিশনের মধ্যে ইন্টারফেস স্থিতিশীল রাখতে তৈরি করতে পারে। প্ল্যাটফর্ম এবং বিক্রেতা নীতি লেখক উভয়ই নীতি লেখা চালিয়ে যেতে পারেন যেমনটি আজ লেখা হয়েছে।

প্ল্যাটফর্ম-পাবলিক নীতি রপ্তানি করা হয়েছে allow source_foo target_bar: class perm ; বিক্রেতা নীতির অংশ হিসাবে অন্তর্ভুক্ত করা হয়. সংকলনের সময় (যার সাথে সংশ্লিষ্ট সংস্করণ রয়েছে) এটি নীতিতে রূপান্তরিত হয় যা ডিভাইসের বিক্রেতার অংশে যাবে (রূপান্তরিত কমন ইন্টারমিডিয়েট ল্যাঙ্গুয়েজে (সিআইএল) দেখানো হয়েছে):

 (allow source_foo_vN target_bar_vN (class (perm)))

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

নীতির পার্থক্য

স্বয়ংক্রিয়ভাবে প্রতিটি প্রকারের শেষে _v N যোগ করে বৈশিষ্ট্যগুলি তৈরি করা সংস্করণের পার্থক্য জুড়ে বৈশিষ্ট্যগুলির ম্যাপিং ছাড়া কিছুই করে না। অ্যান্ড্রয়েড বৈশিষ্ট্যগুলির জন্য সংস্করণগুলির মধ্যে একটি ম্যাপিং এবং সেই বৈশিষ্ট্যগুলির প্রকারের ম্যাপিং বজায় রাখে৷ এটি পূর্বোক্ত ম্যাপিং ফাইলগুলিতে বিবৃতি সহ করা হয়, যেমন (CIL):

(typeattributeset foo_vN (foo))

প্ল্যাটফর্ম আপগ্রেড

নিম্নলিখিত বিভাগটি প্ল্যাটফর্ম আপগ্রেডের জন্য পরিস্থিতির বিবরণ দেয়।

একই ধরনের

এই দৃশ্যটি ঘটে যখন একটি বস্তু নীতি সংস্করণে লেবেল পরিবর্তন করে না। এটি উৎস এবং লক্ষ্য প্রকারের জন্য একই এবং /dev/binder সাথে দেখা যায়, যা সমস্ত রিলিজে binder_device লেবেল করা হয়। এটি রূপান্তরিত নীতিতে উপস্থাপন করা হয়েছে:

binder_device_v1 … binder_device_vN

v1 → v2 থেকে আপগ্রেড করার সময়, প্ল্যাটফর্ম নীতিতে থাকতে হবে:

type binder_device; -> (type binder_device) (in CIL)

v1 ম্যাপিং ফাইলে (CIL):

(typeattributeset binder_device_v1 (binder_device))

v2 ম্যাপিং ফাইলে (CIL):

(typeattributeset binder_device_v2 (binder_device))

v1 ভেন্ডর পলিসিতে (CIL):

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

v2 ভেন্ডর পলিসিতে (CIL):

(typeattribute binder_device_v2)
(allow binder_device_v2 …)

নতুন ধরনের

এই দৃশ্যটি ঘটে যখন প্ল্যাটফর্ম একটি নতুন ধরনের যোগ করে, যা নতুন বৈশিষ্ট্য যোগ করার সময় বা নীতি কঠোর করার সময় ঘটতে পারে।

নতুন বৈশিষ্ট্য। যখন টাইপটি এমন একটি বস্তুকে লেবেল করে যা পূর্বে বিদ্যমান ছিল না (যেমন একটি নতুন পরিষেবা প্রক্রিয়া), বিক্রেতা কোড পূর্বে এটির সাথে সরাসরি যোগাযোগ করেনি তাই কোন সংশ্লিষ্ট নীতি বিদ্যমান নেই। টাইপের সাথে সম্পর্কিত নতুন বৈশিষ্ট্যটির পূর্ববর্তী সংস্করণে একটি বৈশিষ্ট্য নেই এবং তাই সেই সংস্করণটিকে লক্ষ্য করে ম্যাপিং ফাইলে একটি এন্ট্রির প্রয়োজন হবে না।
নীতি কঠোরকরণ. যখন টাইপ পলিসি হার্ডনিং প্রতিনিধিত্ব করে, তখন নতুন টাইপ অ্যাট্রিবিউটকে অবশ্যই আগেরটির সাথে সম্পর্কিত অ্যাট্রিবিউটের একটি চেইনের সাথে লিঙ্ক করতে হবে (পূর্ববর্তী উদাহরণের মতো যা /sys/A sysfs থেকে sysfs_A এ পরিবর্তন করা হয়েছে)। বিক্রেতা কোড sysfs এ অ্যাক্সেস সক্ষম করে এমন একটি নিয়মের উপর নির্ভর করে এবং সেই নিয়মটিকে নতুন ধরনের বৈশিষ্ট্য হিসেবে অন্তর্ভুক্ত করতে হবে।

v1 → v2 থেকে আপগ্রেড করার সময়, প্ল্যাটফর্ম নীতিতে থাকতে হবে:

type sysfs_A; -> (type sysfs_A) (in CIL)
type sysfs; (type sysfs) (in CIL)

v1 ম্যাপিং ফাইলে (CIL):

(typeattributeset sysfs_v1 (sysfs sysfs_A))

v2 ম্যাপিং ফাইলে (CIL):

(typeattributeset sysfs_v2 (sysfs))
(typeattributeset sysfs_A_v2 (sysfs_A))

v1 ভেন্ডর পলিসিতে (CIL):

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

v2 ভেন্ডর পলিসিতে (CIL):

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

অপসারিত প্রকার

এই (বিরল) দৃশ্যটি ঘটে যখন একটি টাইপ সরানো হয়, যা ঘটতে পারে যখন অন্তর্নিহিত বস্তু:

থেকে যায় কিন্তু একটি ভিন্ন লেবেল পায়।
প্ল্যাটফর্ম দ্বারা সরানো হয়.

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

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

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

উদাহরণ সংস্করণ 1: ভেঙে পড়ার ধরন (sysfs_A সরানো হচ্ছে)

v1 → v2 থেকে আপগ্রেড করার সময়, প্ল্যাটফর্ম নীতিতে থাকতে হবে:

type sysfs; (type sysfs) (in CIL)

v1 ম্যাপিং ফাইলে (CIL):

(typeattributeset sysfs_v1 (sysfs))
(type sysfs_A) # in case vendors used the sysfs_A label on objects
(typeattributeset sysfs_A_v1 (sysfs sysfs_A))

v2 ম্যাপিং ফাইলে (CIL):

(typeattributeset sysfs_v2 (sysfs))

v1 ভেন্ডর পলিসিতে (CIL):

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

v2 ভেন্ডর পলিসিতে (CIL):

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

উদাহরণ সংস্করণ 2: সম্পূর্ণরূপে সরানো হচ্ছে (foo টাইপ)

v1 → v2 থেকে আপগ্রেড করার সময়, প্ল্যাটফর্ম নীতিতে থাকতে হবে:

# nothing - we got rid of the type

v1 ম্যাপিং ফাইলে (CIL):

(type foo) #needed in case vendors used the foo label on objects
(typeattributeset foo_v1 (foo))

v2 ম্যাপিং ফাইলে (CIL):

# nothing - get rid of it

v1 ভেন্ডর পলিসিতে (CIL):

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

v2 ভেন্ডর পলিসিতে (CIL):

(typeattribute sysfs_v2)
(allow sysfs_v2 …)

নতুন ক্লাস/অনুমতি

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

বিক্রেতা নীতির দ্বারা তৈরি বা প্রসারিত করা যেতে পারে এমন সমস্ত ডোমেনকে বাধা ছাড়াই নতুন ক্লাস ব্যবহার করার অনুমতি দেওয়ার জন্য, প্ল্যাটফর্ম নীতিতে অনুরূপ একটি নিয়ম অন্তর্ভুক্ত করতে হবে:

allow {domain -coredomain} *:new_class perm;

এমনকি বিক্রেতা ইমেজ অ্যাক্সেস লাভ করে তা নিশ্চিত করার জন্য এর জন্য সমস্ত ইন্টারফেস (পাবলিক পলিসি) ধরনের অ্যাক্সেসের অনুমতি দেওয়ার নীতির প্রয়োজন হতে পারে। যদি এটি অগ্রহণযোগ্য নিরাপত্তা নীতিতে পরিণত হয় (যেমন এটি পরিষেবা ব্যবস্থাপকের পরিবর্তনের সাথে হতে পারে), একটি বিক্রেতা আপগ্রেড সম্ভবত জোরপূর্বক হতে পারে।

ক্লাস/অনুমতি সরানো হয়েছে

এই দৃশ্যটি ঘটে যখন একটি অবজেক্ট ম্যানেজারকে সরিয়ে দেওয়া হয় (যেমন ZygoteConnection অবজেক্ট ম্যানেজার) এবং সমস্যা সৃষ্টি করা উচিত নয়। অবজেক্ট ম্যানেজার ক্লাস এবং অনুমতিগুলি নীতিতে সংজ্ঞায়িত থাকতে পারে যতক্ষণ না বিক্রেতা সংস্করণ এটি ব্যবহার করে না। এটি সংশ্লিষ্ট ম্যাপিং ফাইলে সংজ্ঞা যোগ করে করা হয়।

নতুন/রিলেবেল করা ধরনের জন্য বিক্রেতা কাস্টমাইজেশন

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

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

অ্যান্ড্রয়েড 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 ভেন্ডর বাইনারিগুলিতে অ্যাক্সেসের প্রয়োজন সেগুলিকে ভেন্ডর পার্টিশনে সরানো উচিত এবং এইভাবে, 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 বৈশিষ্ট্য রয়েছে)।

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

প্ল্যাটফর্ম-পাবলিক পলিসি হল Android 8.0 আর্কিটেকচার মডেলের সাথে সঙ্গতিপূর্ণ করার মূল ভিত্তি শুধুমাত্র v1 এবং v2 থেকে প্ল্যাটফর্ম নীতির মিলন বজায় না রেখে। বিক্রেতারা প্ল্যাটফর্ম নীতির একটি উপসেটের সংস্পর্শে আসে যাতে ব্যবহারযোগ্য প্রকার এবং বৈশিষ্ট্য এবং সেই ধরনের এবং বৈশিষ্ট্যগুলির নিয়ম থাকে যা পরে বিক্রেতা নীতির অংশ হয়ে যায় (অর্থাৎ, vendor_sepolicy.cil )।

প্রকার এবং নিয়মগুলি স্বয়ংক্রিয়ভাবে বিক্রেতা-উত্পাদিত নীতিতে attribute_v N তে অনুবাদ করা হয় যাতে সমস্ত প্ল্যাটফর্ম-প্রদত্ত প্রকারগুলি সংস্করণযুক্ত বৈশিষ্ট্য (তবে বৈশিষ্ট্যগুলি সংস্করণ করা হয় না)। প্ল্যাটফর্মটি কংক্রিট ধরণের ম্যাপিংয়ের জন্য দায়ী যা এটি যথাযথ বৈশিষ্ট্যগুলির মধ্যে প্রদান করে তা নিশ্চিত করার জন্য যে বিক্রেতা নীতি কাজ করে চলেছে এবং একটি নির্দিষ্ট সংস্করণের জন্য প্রদত্ত নিয়মগুলি অন্তর্ভুক্ত রয়েছে। প্ল্যাটফর্ম-পাবলিক নীতি এবং বিক্রেতা নীতির সমন্বয় স্বাধীন প্ল্যাটফর্ম এবং বিক্রেতা বিল্ডের অনুমতি দেওয়ার Android 8.0 আর্কিটেকচার মডেল লক্ষ্যকে সন্তুষ্ট করে।

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

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

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

sysfs → sysfs_A বা mediaserver → audioserver এর মতো অবজেক্ট লেবেল পরিবর্তনের জন্য, এই ম্যাপিং তৈরি করা অ-তুচ্ছ (এবং উপরের উদাহরণগুলিতে বর্ণনা করা হয়েছে)। প্ল্যাটফর্ম নীতি রক্ষণাবেক্ষণকারীদের অবশ্যই নির্ধারণ করতে হবে কিভাবে অবজেক্টের ট্রানজিশন পয়েন্টে ম্যাপিং তৈরি করতে হয়, যার জন্য অবজেক্ট এবং তাদের নির্ধারিত লেবেলের মধ্যে সম্পর্ক বোঝা এবং কখন এটি ঘটে তা নির্ধারণ করা প্রয়োজন। পিছনের সামঞ্জস্যের জন্য, এই জটিলতাটি প্ল্যাটফর্মের দিকে পরিচালনা করা প্রয়োজন, যা একমাত্র পার্টিশন যা উন্নীত হতে পারে।

সংস্করণ uprevs

সরলতার জন্য, অ্যান্ড্রয়েড প্ল্যাটফর্ম একটি সেপলিসি সংস্করণ প্রকাশ করে যখন একটি নতুন রিলিজ শাখা কাটা হয়। উপরে বর্ণিত হিসাবে, সংস্করণ নম্বরটি PLATFORM_SEPOLICY_VERSION এ রয়েছে এবং এটি MM.nn ফর্মের, যেখানে MM SDK মানের সাথে মিলে যায় এবং nn হল /platform/system/sepolicy. উদাহরণস্বরূপ, Kitkat-এর জন্য 19.0 , Lollipop-এর জন্য 21.0 , Lollipop-MR1-এর জন্য 22.0 Marshmallow-এর জন্য 23.0 , Nougat-এর জন্য 24.0 , Nougat-MR1-এর জন্য 25.0 , Oreo-এর জন্য 26.0 , Oreo-MR1-এর জন্য 27.0 , এবং Android-s-এর জন্য 29.0-এর জন্য 28.0 . সর্বদা পূর্ণ সংখ্যা। উদাহরণস্বরূপ, যদি কোনো সংস্করণে একটি এমআর বাম্প system/sepolicy/public -এ একটি বেমানান পরিবর্তনের প্রয়োজন হয় কিন্তু একটি API বাম্প নয়, তাহলে সেই সেপলিসি সংস্করণটি হতে পারে: vN.1 । একটি ডেভেলপমেন্ট শাখায় উপস্থিত সংস্করণটি শিপিং-ডিভাইস 10000.0 কখনও ব্যবহার করা যাবে না।

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

একাধিক বৈশিষ্ট্যের কর্মক্ষমতা প্রভাব

যেমন https://github.com/SELinuxProject/cil/issues/9 এ বর্ণনা করা হয়েছে, একটি টাইপের জন্য নির্ধারিত প্রচুর অ্যাট্রিবিউটের ফলে নীতি ক্যাশে মিস হলে কর্মক্ষমতা সমস্যা দেখা দেয়।

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

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

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

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

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

এটি করার জন্য, অংশীদারদের আশা করা হয়:

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

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

(typeattributeset foo_type_N (foo_type))
(expandtypeattribute foo_type_N true)
(typeattribute foo_type_N)

যদি bar_type N+1 সিস্টেম_এক্সট-এ যোগ করা হয় এবং যদি bar_type N বিক্রেতার জন্য foo_type এ ম্যাপ করা হয়, N .cil থেকে আপডেট করা যেতে পারে

(typeattributeset foo_type_N (foo_type))

থেকে

(typeattributeset foo_type_N (foo_type bar_type))

এবং তারপর N+1 system_ext এর পার্টিশনে ইনস্টল করুন। N বিক্রেতা N+1 system_ext-এর foo_type এবং bar_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 অনুমতি

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

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