SELinux প্রয়োগ করুন, SELinux প্রয়োগ করুন

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

কী ফাইল

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

সাধারণভাবে, আপনার system/sepolicy ফাইলগুলি সরাসরি পরিবর্তন করা উচিত নয়। পরিবর্তে, /device/ manufacturer / device-name /sepolicy ডিরেক্টরিতে আপনার নিজস্ব ডিভাইস-নির্দিষ্ট নীতি ফাইল যোগ করুন বা সম্পাদনা করুন। অ্যান্ড্রয়েড 8.0 এবং উচ্চতর সংস্করণে, আপনি এই ফাইলগুলিতে যে পরিবর্তনগুলি করেন তা শুধুমাত্র আপনার বিক্রেতা ডিরেক্টরির নীতিকে প্রভাবিত করবে৷ অ্যান্ড্রয়েড 8.0 এবং পরবর্তীতে পাবলিক সিপলিসি আলাদা করার বিষয়ে আরও বিশদের জন্য, অ্যান্ড্রয়েড 8.0+ এ কাস্টমাইজ করা এসইপলিসি দেখুন। Android সংস্করণ নির্বিশেষে, আপনি এখনও এই ফাইলগুলি সংশোধন করছেন:

নীতি ফাইল

যে ফাইলগুলি *.te দিয়ে শেষ হয় সেগুলি হল SELinux পলিসি সোর্স ফাইল, যা ডোমেন এবং তাদের লেবেলগুলিকে সংজ্ঞায়িত করে৷ আপনাকে /device/ manufacturer / device-name /sepolicy এ নতুন নীতি ফাইল তৈরি করতে হতে পারে, কিন্তু যেখানে সম্ভব আপনার বিদ্যমান ফাইলগুলি আপডেট করার চেষ্টা করা উচিত।

প্রসঙ্গ ফাইল

প্রসঙ্গ ফাইলগুলি যেখানে আপনি আপনার বস্তুর জন্য লেবেল নির্দিষ্ট করেন৷

• file_contexts ফাইলগুলিতে লেবেল বরাদ্দ করে এবং বিভিন্ন ইউজারস্পেস উপাদান দ্বারা ব্যবহৃত হয়। আপনি নতুন নীতি তৈরি করার সাথে সাথে ফাইলগুলিতে নতুন লেবেল বরাদ্দ করতে এই ফাইলটি তৈরি করুন বা আপডেট করুন৷ নতুন file_contexts প্রয়োগ করতে, ফাইল সিস্টেম চিত্রটি পুনর্নির্মাণ করুন বা পুনরায় লেবেল করার জন্য ফাইলটিতে restorecon চালান। আপগ্রেডের সময়, file_contexts পরিবর্তনগুলি আপগ্রেডের অংশ হিসাবে সিস্টেম এবং ব্যবহারকারী ডেটা পার্টিশনে স্বয়ংক্রিয়ভাবে প্রয়োগ করা হয়। আপনার init-এ restorecon_recursive কল যোগ করে অন্যান্য পার্টিশনে আপগ্রেড করার সময় পরিবর্তনগুলি স্বয়ংক্রিয়ভাবে প্রয়োগ করা যেতে পারে। board .rc ফাইলে পার্টিশন বসানোর পর রিড-রাইট করুন।
• genfs_contexts ফাইল সিস্টেমে লেবেল বরাদ্দ করে, যেমন proc বা vfat যা বর্ধিত বৈশিষ্ট্য সমর্থন করে না। এই কনফিগারেশনটি কার্নেল নীতির অংশ হিসাবে লোড করা হয়েছে তবে পরিবর্তনগুলি ইন-কোর ইনোডগুলির জন্য কার্যকর নাও হতে পারে, পরিবর্তনটি সম্পূর্ণরূপে প্রয়োগ করার জন্য একটি রিবুট বা আনমাউন্ট করা এবং পুনরায় মাউন্ট করা প্রয়োজন। context=mount বিকল্পটি ব্যবহার করে vfat মতো নির্দিষ্ট মাউন্টগুলিতেও নির্দিষ্ট লেবেল বরাদ্দ করা যেতে পারে।
• property_contexts অ্যান্ড্রয়েড সিস্টেমের বৈশিষ্ট্যগুলিতে লেবেলগুলি বরাদ্দ করে যা সেগুলিকে কী প্রক্রিয়াগুলি সেট করতে পারে তা নিয়ন্ত্রণ করে৷ এই কনফিগারেশন স্টার্টআপের সময় init প্রক্রিয়া দ্বারা পড়া হয়।
• service_contexts অ্যান্ড্রয়েড বাইন্ডার পরিষেবাগুলিতে লেবেলগুলি বরাদ্দ করে যা নিয়ন্ত্রণ করতে কী প্রক্রিয়াগুলি যোগ করতে পারে (নিবন্ধন) এবং পরিষেবাটির জন্য একটি বাইন্ডার রেফারেন্স খুঁজে (লুকআপ)। এই কনফিগারেশনটি স্টার্টআপের সময় servicemanager প্রক্রিয়া দ্বারা পড়া হয়।
• seapp_contexts অ্যাপ প্রসেস এবং /data/data ডিরেক্টরিতে লেবেল বরাদ্দ করে। এই কনফিগারেশনটি প্রতিটি অ্যাপ লঞ্চের সময় zygote প্রক্রিয়া দ্বারা এবং স্টার্টআপের সময় installd করে পড়া হয়।
• mac_permissions.xml অ্যাপগুলিকে তাদের স্বাক্ষর এবং ঐচ্ছিকভাবে তাদের প্যাকেজ নামের উপর ভিত্তি করে একটি seinfo ট্যাগ প্রদান করে। seinfo ট্যাগটি সেই seinfo ট্যাগ সহ সমস্ত অ্যাপে একটি নির্দিষ্ট লেবেল বরাদ্দ করতে seapp_contexts ফাইলে একটি কী হিসাবে ব্যবহার করা যেতে পারে। এই কনফিগারেশনটি স্টার্টআপের সময় system_server দ্বারা পড়া হয়।
• keystore2_key_contexts কীস্টোর 2.0 নামস্থানে লেবেল বরাদ্দ করে। এই নামস্থান keystore2 ডেমন দ্বারা প্রয়োগ করা হয়। কীস্টোর সর্বদা UID/AID ভিত্তিক নামস্থান প্রদান করেছে। কীস্টোর 2.0 অতিরিক্তভাবে সেপলিসি সংজ্ঞায়িত নামস্থান প্রয়োগ করে। এই ফাইলের বিন্যাস এবং নিয়মাবলীর একটি বিশদ বিবরণ এখানে পাওয়া যাবে।

BoardConfig.mk makefile

নীতি এবং প্রসঙ্গ ফাইলগুলি সম্পাদনা বা যোগ করার পরে, sepolicy সাবডিরেক্টরি এবং প্রতিটি নতুন নীতি ফাইলের উল্লেখ করতে আপনার /device/ manufacturer / device-name /BoardConfig.mk makefile আপডেট করুন। BOARD_SEPOLICY ভেরিয়েবল সম্পর্কে আরও তথ্যের জন্য, system/sepolicy/README ফাইলটি দেখুন।

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

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

যখন নতুন নীতি ফাইল এবং BoardConfig.mk আপডেটগুলি থাকে, তখন নতুন নীতি সেটিংস স্বয়ংক্রিয়ভাবে চূড়ান্ত কার্নেল নীতি ফাইলে তৈরি হয়। ডিভাইসে সিপলিসি কীভাবে তৈরি করা হয় সে সম্পর্কে আরও তথ্যের জন্য, বিল্ডিং সেপলিসি দেখুন।

বাস্তবায়ন

SELinux দিয়ে শুরু করতে:

1. কার্নেলে SELinux সক্ষম করুন: CONFIG_SECURITY_SELINUX=y
2. kernel_cmdline বা bootconfig প্যারামিটার পরিবর্তন করুন যাতে:

   BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive

   বা

   BOARD_BOOTCONFIG := androidboot.selinux=permissive

   এটি শুধুমাত্র ডিভাইসের জন্য নীতির প্রাথমিক বিকাশের জন্য। আপনার একটি প্রাথমিক বুটস্ট্র্যাপ নীতি পাওয়ার পরে, এই প্যারামিটারটি সরিয়ে ফেলুন যাতে আপনার ডিভাইসটি কার্যকর হয় বা এটি CTS ব্যর্থ হয়।
3. অনুমতিমূলকভাবে সিস্টেম বুট আপ করুন এবং বুট করার সময় কি অস্বীকার করা হয়েছে তা দেখুন:
   উবুন্টু 14.04 বা তার পরবর্তীতে:

   adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
   

   উবুন্টু 12.04 এ:

   adb pull /sys/fs/selinux/policy
   adb logcat -b all | audit2allow -p policy
   

4. সতর্কতার জন্য আউটপুট মূল্যায়ন করুন যা init: Warning! Service name needs a SELinux domain defined; please fix! নির্দেশাবলী এবং সরঞ্জামগুলির জন্য বৈধতা দেখুন।
5. ডিভাইসগুলি এবং অন্যান্য নতুন ফাইলগুলি সনাক্ত করুন যেগুলির লেবেলিং প্রয়োজন৷
6. আপনার বস্তুর জন্য বিদ্যমান বা নতুন লেবেল ব্যবহার করুন. জিনিসগুলিকে আগে কীভাবে লেবেল করা হয়েছিল তা দেখতে *_contexts ফাইলগুলি দেখুন এবং একটি নতুন বরাদ্দ করতে লেবেলের অর্থের জ্ঞান ব্যবহার করুন৷ আদর্শভাবে, এটি একটি বিদ্যমান লেবেল যা নীতির সাথে খাপ খায়, কিন্তু কখনও কখনও একটি নতুন লেবেল প্রয়োজন হয় এবং সেই লেবেলে অ্যাক্সেসের জন্য নিয়ম প্রয়োজন হয়৷ উপযুক্ত প্রসঙ্গ ফাইলে আপনার লেবেল যোগ করুন।
7. ডোমেন/প্রসেস সনাক্ত করুন যেগুলির নিজস্ব নিরাপত্তা ডোমেন থাকা উচিত। আপনাকে সম্ভবত প্রতিটির জন্য একটি সম্পূর্ণ নতুন নীতি লিখতে হবে। init থেকে উদ্ভূত সমস্ত পরিষেবা, উদাহরণস্বরূপ, তাদের নিজস্ব থাকা উচিত। নিম্নলিখিত কমান্ডগুলি যেগুলি চলমান রয়েছে তা প্রকাশ করতে সহায়তা করে (কিন্তু সমস্ত পরিষেবার জন্য এই ধরনের চিকিত্সার প্রয়োজন):
   

   adb shell su -c ps -Z | grep init
   

   adb shell su -c dmesg | grep 'avc: '
   

8. রিভিউ init. device .rc কোনো ডোমেন টাইপ নেই এমন ডোমেন সনাক্ত করতে। আপনার ডেভেলপমেন্ট প্রক্রিয়ার প্রথম দিকে তাদের একটি ডোমেন দিন যাতে init এ নিয়ম যোগ না হয় বা অন্যথায় তাদের নিজস্ব নীতির সাথে init অ্যাক্সেসগুলিকে বিভ্রান্ত করে।
9. BOARD_SEPOLICY_* ভেরিয়েবল ব্যবহার করতে BOARD_CONFIG.mk সেট আপ করুন। এটি সেট আপ করার বিষয়ে বিস্তারিত জানার জন্য system/sepolicy README দেখুন।
10. init পরীক্ষা করুন। device .rc এবং fstab। device ফাইল এবং নিশ্চিত করুন যে mount প্রতিটি ব্যবহার একটি সঠিকভাবে লেবেল করা ফাইল সিস্টেমের সাথে সামঞ্জস্যপূর্ণ বা একটি context= mount বিকল্প নির্দিষ্ট করা আছে।
11. প্রতিটি অস্বীকারের মধ্য দিয়ে যান এবং প্রতিটিকে সঠিকভাবে পরিচালনা করার জন্য SELinux নীতি তৈরি করুন। কাস্টমাইজেশনে উদাহরণগুলি দেখুন।

আপনার AOSP-এর নীতিগুলি দিয়ে শুরু করা উচিত এবং তারপরে আপনার নিজস্ব কাস্টমাইজেশনের জন্য সেগুলি তৈরি করা উচিত। নীতি কৌশল সম্বন্ধে আরও তথ্যের জন্য এবং এই ধাপগুলির কয়েকটির ঘনিষ্ঠভাবে দেখার জন্য, SELinux নীতি লেখা দেখুন।

কেস ব্যবহার করুন

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

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

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

সিস্টেম ফাইল: সিস্টেম ফাইলের ক্লাস বিবেচনা করুন যেগুলি শুধুমাত্র সিস্টেম সার্ভার দ্বারা সংশোধন করা উচিত। তারপরও, যেহেতু netd , init , এবং vold রুট হিসাবে চালানো হয়, তারা সেই সিস্টেম ফাইলগুলি অ্যাক্সেস করতে পারে। সুতরাং যদি netd আপস করা হয়, এটি সেই ফাইলগুলি এবং সম্ভাব্য সিস্টেম সার্ভারের সাথে আপস করতে পারে।

SELinux-এর মাধ্যমে, আপনি সেই ফাইলগুলিকে সিস্টেম সার্ভার ডেটা ফাইল হিসাবে চিহ্নিত করতে পারেন। অতএব, একমাত্র ডোমেইন যা তাদের পড়ার/লিখতে অ্যাক্সেস করেছে তা হল সিস্টেম সার্ভার। এমনকি যদি netd কম্প্রোমাইজড হয়ে যায়, এটি ডোমেনগুলিকে সিস্টেম সার্ভার ডোমেনে স্যুইচ করতে পারে না এবং সেই সিস্টেম ফাইলগুলি অ্যাক্সেস করতে পারে না যদিও এটি রুট হিসাবে চলে।

অ্যাপ ডেটা: আরেকটি উদাহরণ হল ফাংশনের ক্লাস যা রুট হিসাবে চালাতে হবে কিন্তু অ্যাপ ডেটা অ্যাক্সেস করতে হবে না। এটি অবিশ্বাস্যভাবে কার্যকর কারণ বিস্তৃত দাবি করা যেতে পারে, যেমন অ্যাপ ডেটার সাথে সম্পর্কিত কিছু ডোমেন ইন্টারনেট অ্যাক্সেস করা নিষিদ্ধ।

setattr: chmod এবং chown এর মতো কমান্ডের জন্য, আপনি ফাইলের সেট সনাক্ত করতে পারেন যেখানে সংশ্লিষ্ট ডোমেন setattr পরিচালনা করতে পারে। এর বাইরের যেকোনো কিছুকে এই পরিবর্তনগুলি থেকে নিষিদ্ধ করা যেতে পারে, এমনকি রুট দ্বারাও। সুতরাং একটি অ্যাপ chmod চালাতে পারে এবং সেই লেবেলযুক্ত app_data_files বিরুদ্ধে chown কিন্তু shell_data_files বা system_data_files নয়।

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

কী ফাইল

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

সাধারণভাবে, আপনার system/sepolicy ফাইলগুলি সরাসরি পরিবর্তন করা উচিত নয়। পরিবর্তে, /device/ manufacturer / device-name /sepolicy ডিরেক্টরিতে আপনার নিজস্ব ডিভাইস-নির্দিষ্ট নীতি ফাইল যোগ করুন বা সম্পাদনা করুন। অ্যান্ড্রয়েড 8.0 এবং উচ্চতর সংস্করণে, আপনি এই ফাইলগুলিতে যে পরিবর্তনগুলি করেন তা শুধুমাত্র আপনার বিক্রেতা ডিরেক্টরির নীতিকে প্রভাবিত করবে৷ অ্যান্ড্রয়েড 8.0 এবং পরবর্তীতে পাবলিক সিপলিসি আলাদা করার বিষয়ে আরও বিশদের জন্য, অ্যান্ড্রয়েড 8.0+ এ কাস্টমাইজ করা এসইপলিসি দেখুন। Android সংস্করণ নির্বিশেষে, আপনি এখনও এই ফাইলগুলি সংশোধন করছেন:

নীতি ফাইল

যে ফাইলগুলি *.te দিয়ে শেষ হয় সেগুলি হল SELinux পলিসি সোর্স ফাইল, যা ডোমেন এবং তাদের লেবেলগুলিকে সংজ্ঞায়িত করে৷ আপনাকে /device/ manufacturer / device-name /sepolicy এ নতুন নীতি ফাইল তৈরি করতে হতে পারে, কিন্তু যেখানে সম্ভব আপনার বিদ্যমান ফাইলগুলি আপডেট করার চেষ্টা করা উচিত।

প্রসঙ্গ ফাইল

প্রসঙ্গ ফাইলগুলি যেখানে আপনি আপনার বস্তুর জন্য লেবেল নির্দিষ্ট করেন৷

• file_contexts ফাইলগুলিতে লেবেল বরাদ্দ করে এবং বিভিন্ন ইউজারস্পেস উপাদান দ্বারা ব্যবহৃত হয়। আপনি নতুন নীতি তৈরি করার সাথে সাথে ফাইলগুলিতে নতুন লেবেল বরাদ্দ করতে এই ফাইলটি তৈরি করুন বা আপডেট করুন৷ নতুন file_contexts প্রয়োগ করতে, ফাইল সিস্টেম চিত্রটি পুনর্নির্মাণ করুন বা পুনরায় লেবেল করার জন্য ফাইলটিতে restorecon চালান। আপগ্রেডের সময়, file_contexts পরিবর্তনগুলি আপগ্রেডের অংশ হিসাবে সিস্টেম এবং ব্যবহারকারী ডেটা পার্টিশনে স্বয়ংক্রিয়ভাবে প্রয়োগ করা হয়। আপনার init-এ restorecon_recursive কল যোগ করে অন্যান্য পার্টিশনে আপগ্রেড করার সময় পরিবর্তনগুলি স্বয়ংক্রিয়ভাবে প্রয়োগ করা যেতে পারে। board .rc ফাইলটি পার্টিশন মাউন্ট করার পর রিড-রাইট করুন।
• genfs_contexts ফাইল সিস্টেমে লেবেল বরাদ্দ করে, যেমন proc বা vfat যা বর্ধিত বৈশিষ্ট্য সমর্থন করে না। এই কনফিগারেশনটি কার্নেল নীতির অংশ হিসাবে লোড করা হয়েছে তবে পরিবর্তনগুলি ইন-কোর ইনোডগুলির জন্য কার্যকর নাও হতে পারে, পরিবর্তনটি সম্পূর্ণরূপে প্রয়োগ করার জন্য একটি রিবুট বা আনমাউন্ট করা এবং পুনরায় মাউন্ট করা প্রয়োজন। context=mount বিকল্পটি ব্যবহার করে vfat মতো নির্দিষ্ট মাউন্টগুলিতেও নির্দিষ্ট লেবেল বরাদ্দ করা যেতে পারে।
• property_contexts অ্যান্ড্রয়েড সিস্টেমের বৈশিষ্ট্যগুলিতে লেবেলগুলি বরাদ্দ করে যা সেগুলিকে কী প্রক্রিয়াগুলি সেট করতে পারে তা নিয়ন্ত্রণ করে৷ এই কনফিগারেশন স্টার্টআপের সময় init প্রক্রিয়া দ্বারা পড়া হয়।
• service_contexts অ্যান্ড্রয়েড বাইন্ডার পরিষেবাগুলিতে লেবেলগুলি বরাদ্দ করে যা নিয়ন্ত্রণ করতে কী প্রক্রিয়াগুলি যোগ করতে পারে (নিবন্ধন) এবং পরিষেবাটির জন্য একটি বাইন্ডার রেফারেন্স খুঁজে (লুকআপ)। এই কনফিগারেশনটি স্টার্টআপের সময় servicemanager প্রক্রিয়া দ্বারা পড়া হয়।
• seapp_contexts অ্যাপ প্রসেস এবং /data/data ডিরেক্টরিতে লেবেল বরাদ্দ করে। এই কনফিগারেশনটি প্রতিটি অ্যাপ লঞ্চের সময় zygote প্রক্রিয়া দ্বারা এবং স্টার্টআপের সময় installd করে পড়া হয়।
• mac_permissions.xml অ্যাপগুলিকে তাদের স্বাক্ষর এবং ঐচ্ছিকভাবে তাদের প্যাকেজ নামের উপর ভিত্তি করে একটি seinfo ট্যাগ প্রদান করে। seinfo ট্যাগটি সেই seinfo ট্যাগ সহ সমস্ত অ্যাপে একটি নির্দিষ্ট লেবেল বরাদ্দ করতে seapp_contexts ফাইলে একটি কী হিসাবে ব্যবহার করা যেতে পারে। এই কনফিগারেশনটি স্টার্টআপের সময় system_server দ্বারা পড়া হয়।
• keystore2_key_contexts কীস্টোর 2.0 নামস্থানে লেবেল বরাদ্দ করে। এই নামস্থান keystore2 ডেমন দ্বারা প্রয়োগ করা হয়। কীস্টোর সর্বদা UID/AID ভিত্তিক নামস্থান প্রদান করেছে। কীস্টোর 2.0 অতিরিক্তভাবে সেপলিসি সংজ্ঞায়িত নামস্থান প্রয়োগ করে। এই ফাইলের বিন্যাস এবং নিয়মাবলীর একটি বিশদ বিবরণ এখানে পাওয়া যাবে।

BoardConfig.mk makefile

নীতি এবং প্রসঙ্গ ফাইলগুলি সম্পাদনা বা যোগ করার পরে, sepolicy সাবডিরেক্টরি এবং প্রতিটি নতুন নীতি ফাইলের উল্লেখ করতে আপনার /device/ manufacturer / device-name /BoardConfig.mk makefile আপডেট করুন। BOARD_SEPOLICY ভেরিয়েবল সম্পর্কে আরও তথ্যের জন্য, system/sepolicy/README ফাইলটি দেখুন।

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

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

যখন নতুন নীতি ফাইল এবং BoardConfig.mk আপডেটগুলি থাকে, তখন নতুন নীতি সেটিংস স্বয়ংক্রিয়ভাবে চূড়ান্ত কার্নেল নীতি ফাইলে তৈরি হয়। ডিভাইসে সিপলিসি কীভাবে তৈরি করা হয় সে সম্পর্কে আরও তথ্যের জন্য, বিল্ডিং সেপলিসি দেখুন।

বাস্তবায়ন

SELinux দিয়ে শুরু করতে:

1. কার্নেলে SELinux সক্ষম করুন: CONFIG_SECURITY_SELINUX=y
2. kernel_cmdline বা bootconfig প্যারামিটার পরিবর্তন করুন যাতে:

   BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive

   বা

   BOARD_BOOTCONFIG := androidboot.selinux=permissive

   এটি শুধুমাত্র ডিভাইসের জন্য নীতির প্রাথমিক বিকাশের জন্য। আপনার একটি প্রাথমিক বুটস্ট্র্যাপ নীতি পাওয়ার পরে, এই প্যারামিটারটি সরিয়ে ফেলুন যাতে আপনার ডিভাইসটি কার্যকর হয় বা এটি CTS ব্যর্থ হয়।
3. অনুমতিমূলকভাবে সিস্টেম বুট আপ করুন এবং বুট করার সময় কি অস্বীকার করা হয়েছে তা দেখুন:
   উবুন্টু 14.04 বা তার পরবর্তীতে:

   adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
   

   উবুন্টু 12.04 এ:

   adb pull /sys/fs/selinux/policy
   adb logcat -b all | audit2allow -p policy
   

4. সতর্কতার জন্য আউটপুট মূল্যায়ন করুন যা init: Warning! Service name needs a SELinux domain defined; please fix! নির্দেশাবলী এবং সরঞ্জামগুলির জন্য বৈধতা দেখুন।
5. ডিভাইসগুলি এবং অন্যান্য নতুন ফাইলগুলি সনাক্ত করুন যেগুলির লেবেলিং প্রয়োজন৷
6. আপনার বস্তুর জন্য বিদ্যমান বা নতুন লেবেল ব্যবহার করুন. জিনিসগুলিকে আগে কীভাবে লেবেল করা হয়েছিল তা দেখতে *_contexts ফাইলগুলি দেখুন এবং একটি নতুন বরাদ্দ করতে লেবেলের অর্থের জ্ঞান ব্যবহার করুন৷ আদর্শভাবে, এটি একটি বিদ্যমান লেবেল যা নীতির সাথে খাপ খায়, কিন্তু কখনও কখনও একটি নতুন লেবেল প্রয়োজন হয় এবং সেই লেবেলে অ্যাক্সেসের জন্য নিয়ম প্রয়োজন হয়৷ উপযুক্ত প্রসঙ্গ ফাইলে আপনার লেবেল যোগ করুন।
7. ডোমেন/প্রসেস সনাক্ত করুন যেগুলির নিজস্ব নিরাপত্তা ডোমেন থাকা উচিত। আপনাকে সম্ভবত প্রতিটির জন্য একটি সম্পূর্ণ নতুন নীতি লিখতে হবে। init থেকে উদ্ভূত সমস্ত পরিষেবা, উদাহরণস্বরূপ, তাদের নিজস্ব থাকা উচিত। নিম্নলিখিত কমান্ডগুলি যেগুলি চলমান রয়েছে তা প্রকাশ করতে সহায়তা করে (কিন্তু সমস্ত পরিষেবার জন্য এই ধরনের চিকিত্সা প্রয়োজন):
   

   adb shell su -c ps -Z | grep init
   

   adb shell su -c dmesg | grep 'avc: '
   

8. রিভিউ init. device .rc কোনো ডোমেন টাইপ নেই এমন ডোমেন সনাক্ত করতে। আপনার ডেভেলপমেন্ট প্রক্রিয়ার প্রথম দিকে তাদের একটি ডোমেন দিন যাতে init এ নিয়ম যোগ না হয় বা অন্যথায় তাদের নিজস্ব নীতির সাথে init অ্যাক্সেসগুলিকে বিভ্রান্ত করে।
9. BOARD_SEPOLICY_* ভেরিয়েবল ব্যবহার করতে BOARD_CONFIG.mk সেট আপ করুন। এটি সেট আপ করার বিষয়ে বিস্তারিত জানার জন্য system/sepolicy README দেখুন।
10. init পরীক্ষা করুন। device .rc এবং fstab। device ফাইল এবং নিশ্চিত করুন যে mount প্রতিটি ব্যবহার একটি সঠিকভাবে লেবেল করা ফাইল সিস্টেমের সাথে সামঞ্জস্যপূর্ণ বা একটি context= mount বিকল্প নির্দিষ্ট করা আছে।
11. প্রতিটি অস্বীকারের মধ্য দিয়ে যান এবং প্রতিটিকে সঠিকভাবে পরিচালনা করার জন্য SELinux নীতি তৈরি করুন। কাস্টমাইজেশনে উদাহরণগুলি দেখুন।

আপনার AOSP-এর নীতিগুলি দিয়ে শুরু করা উচিত এবং তারপরে আপনার নিজস্ব কাস্টমাইজেশনের জন্য সেগুলি তৈরি করা উচিত। নীতি কৌশল সম্বন্ধে আরও তথ্যের জন্য এবং এই ধাপগুলির কয়েকটির ঘনিষ্ঠভাবে দেখার জন্য, SELinux নীতি লেখা দেখুন।

কেস ব্যবহার করুন

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

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

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

সিস্টেম ফাইল: সিস্টেম ফাইলের ক্লাস বিবেচনা করুন যেগুলি শুধুমাত্র সিস্টেম সার্ভার দ্বারা সংশোধন করা উচিত। তারপরও, যেহেতু netd , init , এবং vold রুট হিসাবে চালানো হয়, তারা সেই সিস্টেম ফাইলগুলি অ্যাক্সেস করতে পারে। সুতরাং যদি netd আপস করা হয়, এটি সেই ফাইলগুলি এবং সম্ভাব্য সিস্টেম সার্ভারের সাথে আপস করতে পারে।

SELinux-এর মাধ্যমে, আপনি সেই ফাইলগুলিকে সিস্টেম সার্ভার ডেটা ফাইল হিসাবে চিহ্নিত করতে পারেন। অতএব, একমাত্র ডোমেইন যা তাদের পড়ার/লিখতে অ্যাক্সেস করেছে তা হল সিস্টেম সার্ভার। এমনকি যদি netd কম্প্রোমাইজড হয়ে যায়, এটি ডোমেনগুলিকে সিস্টেম সার্ভার ডোমেনে স্যুইচ করতে পারে না এবং সেই সিস্টেম ফাইলগুলি অ্যাক্সেস করতে পারে না যদিও এটি রুট হিসাবে চলে।

অ্যাপ ডেটা: আরেকটি উদাহরণ হল ফাংশনের ক্লাস যা রুট হিসাবে চালাতে হবে কিন্তু অ্যাপ ডেটা অ্যাক্সেস করতে হবে না। এটি অবিশ্বাস্যভাবে কার্যকর কারণ বিস্তৃত দাবি করা যেতে পারে, যেমন অ্যাপ ডেটার সাথে সম্পর্কিত কিছু ডোমেন ইন্টারনেট অ্যাক্সেস করা নিষিদ্ধ।

setattr: chmod এবং chown এর মতো কমান্ডের জন্য, আপনি ফাইলের সেট সনাক্ত করতে পারেন যেখানে সংশ্লিষ্ট ডোমেন setattr পরিচালনা করতে পারে। এর বাইরের যেকোনো কিছুকে এই পরিবর্তনগুলি থেকে নিষিদ্ধ করা যেতে পারে, এমনকি রুট দ্বারাও। সুতরাং একটি অ্যাপ chmod চালাতে পারে এবং সেই লেবেলযুক্ত app_data_files বিরুদ্ধে chown কিন্তু shell_data_files বা system_data_files নয়।