SELinux নীতি লিখুন

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

ডিভাইস আনা

ডিভাইস-নির্দিষ্ট নীতি লেখার সময়, এই পদক্ষেপগুলি অনুসরণ করুন।

অনুমতিমূলক মোডে চালান

যখন একটি ডিভাইস অনুমতিমূলক মোডে থাকে, তখন অস্বীকারগুলি লগ করা হয় কিন্তু প্রয়োগ করা হয় না৷ অনুমতিমূলক মোড দুটি কারণে গুরুত্বপূর্ণ:

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

একটি ডিভাইসকে পারমিসিভ মোডে রাখার সবচেয়ে সহজ উপায় হল কার্নেল কমান্ড লাইন ব্যবহার করা। এটি ডিভাইসের BoardConfig.mk ফাইলে যোগ করা যেতে পারে: platform/device/<vendor>/<target>/BoardConfig.mk । কমান্ড লাইন পরিবর্তন করার পরে, make clean সঞ্চালন করুন, তারপরে make bootimage এবং নতুন বুট চিত্রটি ফ্ল্যাশ করুন।

এর পরে, এর সাথে অনুমতিমূলক মোড নিশ্চিত করুন:

adb shell getenforce

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

তাড়াতাড়ি প্রয়োগ করুন

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

বিদ্যমান নীতি সরান বা মুছুন

একটি নতুন ডিভাইসে স্ক্র্যাচ থেকে ডিভাইস-নির্দিষ্ট নীতি তৈরি করার বেশ কয়েকটি ভাল কারণ রয়েছে, যার মধ্যে রয়েছে:

• নিরাপত্তা নিরীক্ষণ
• অতিমাত্রায় অনুমতিমূলক নীতি
• নীতির আকার হ্রাস
• মৃত নীতি

মূল পরিষেবার অস্বীকৃতির ঠিকানা

মূল পরিষেবাগুলির দ্বারা উত্পন্ন অস্বীকারগুলি সাধারণত ফাইল লেবেলিং দ্বারা সম্বোধন করা হয়। যেমন:

avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0”
dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
tclass=chr_file permissive=1
avc: denied { read write } for pid=1003 name="kgsl-3d0" dev="tmpfs"
scontext=u:r:mediaserver:s0
tcontext=u:object_r:device:s0 tclass=chr_file permissive=1

সঠিকভাবে /dev/kgsl-3d0 লেবেল করে সম্পূর্ণরূপে সমাধান করা হয়। এই উদাহরণে, tcontext হল device । এটি একটি ডিফল্ট প্রসঙ্গ উপস্থাপন করে যেখানে /dev এ থাকা সবকিছুই “ ডিভাইস ” লেবেল গ্রহণ করে যদি না আরও নির্দিষ্ট লেবেল বরাদ্দ করা হয়। শুধুমাত্র এখানে audit2allow থেকে আউটপুট গ্রহণ করলে একটি ভুল এবং অত্যধিক অনুমতিমূলক নিয়ম হবে।

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

অন্যান্য ডিভাইস-নির্দিষ্ট ফাইল যা মূল নীতিতে পূর্বনির্ধারিত প্রকারের সাথে লেবেল করা উচিত:

• ব্লক ডিভাইস
• অডিও ডিভাইস
• ভিডিও ডিভাইস
• সেন্সর
• এনএফসি
• জিপিএস_ডিভাইস
• ফাইল /sys
• ফাইল /proc

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

লেবেল নতুন পরিষেবা এবং ঠিকানা অস্বীকার

Init-লঞ্চ করা পরিষেবাগুলি তাদের নিজস্ব SELinux ডোমেনে চালানোর জন্য প্রয়োজন। নিম্নলিখিত উদাহরণটি "foo" পরিষেবাটিকে তার নিজস্ব SELinux ডোমেনে রাখে এবং এটিকে অনুমতি দেয়।

পরিষেবাটি আমাদের ডিভাইসের init. device .rc ফাইল হিসাবে:

service foo /system/bin/foo
    class core

1. একটি নতুন ডোমেইন "foo" তৈরি করুন
   

   নিম্নলিখিত বিষয়বস্তু সহ device/ manufacturer / device-name /sepolicy/foo.te ফাইলটি তৈরি করুন:

   # foo service
   type foo, domain;
   type foo_exec, exec_type, file_type;
   
   init_daemon_domain(foo)
   

   এটি foo SELinux ডোমেনের প্রাথমিক টেমপ্লেট, যেখানে আপনি সেই এক্সিকিউটেবল দ্বারা সম্পাদিত নির্দিষ্ট ক্রিয়াকলাপের উপর ভিত্তি করে নিয়ম যোগ করতে পারেন।

2. লেবেল /system/bin/foo
   

   device/ manufacturer / device-name /sepolicy/file_contexts এ নিম্নলিখিত যোগ করুন:

   /system/bin/foo   u:object_r:foo_exec:s0
   

   এটি নিশ্চিত করে যে এক্সিকিউটেবলটি সঠিকভাবে লেবেল করা হয়েছে যাতে SELinux সঠিক ডোমেনে পরিষেবাটি চালায়।

3. বুট এবং সিস্টেম ইমেজ তৈরি এবং ফ্ল্যাশ.
4. ডোমেনের জন্য SELinux নিয়মগুলি পরিমার্জন করুন।
   

   প্রয়োজনীয় অনুমতি নির্ধারণ করতে অস্বীকার ব্যবহার করুন. audit2allow টুলটি ভাল নির্দেশিকা প্রদান করে, কিন্তু শুধুমাত্র নীতি লেখার জন্য এটি ব্যবহার করে। শুধু আউটপুট কপি করবেন না।

এনফোর্সিং মোডে ফিরে যান

অনুমতিমূলক মোডে সমস্যা সমাধান করা ভাল, তবে যত তাড়াতাড়ি সম্ভব এনফোর্সিং মোডে ফিরে যান এবং সেখানে থাকার চেষ্টা করুন।

সাধারণ ভুল

ডিভাইস-নির্দিষ্ট নীতিগুলি লেখার সময় সাধারণ ভুলগুলির জন্য এখানে কয়েকটি সমাধান রয়েছে৷

অত্যাচারের অত্যধিক ব্যবহার

নিম্নলিখিত উদাহরণের নিয়ম হল সামনের দরজা লক করা কিন্তু জানালা খোলা রাখার মত:

allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms

উদ্দেশ্য পরিষ্কার: তৃতীয় পক্ষের অ্যাপ ছাড়া সবাই ডিবাগ ডিভাইসে অ্যাক্সেস করতে পারে।

নিয়মটি কয়েকটি উপায়ে ত্রুটিপূর্ণ। untrusted_app বাদ দেওয়া প্রায় কাজ করার জন্য তুচ্ছ কারণ সমস্ত অ্যাপ ঐচ্ছিকভাবে isolated_app ডোমেনে পরিষেবা চালাতে পারে। একইভাবে, যদি AOSP-এ তৃতীয় পক্ষের অ্যাপের জন্য নতুন ডোমেন যোগ করা হয়, তাহলে তাদের কাছে scary_debug_device এও অ্যাক্সেস থাকবে। নিয়ম অত্যধিক অনুমোদিত. বেশিরভাগ ডোমেইন এই ডিবাগিং টুলে অ্যাক্সেস পেয়ে উপকৃত হবে না। নিয়মটি কেবলমাত্র সেই ডোমেনগুলির অনুমতি দেওয়ার জন্য লেখা উচিত ছিল যেগুলির অ্যাক্সেস প্রয়োজন৷

উৎপাদনে ডিবাগ বৈশিষ্ট্য

ডিবাগ বৈশিষ্ট্যগুলি প্রোডাকশন বিল্ডগুলিতে উপস্থিত থাকা উচিত নয় এবং তাদের নীতিতেও থাকা উচিত নয়৷

সবচেয়ে সহজ বিকল্প হল শুধুমাত্র যখন SELinux eng/userdebug বিল্ডে নিষ্ক্রিয় করা থাকে, যেমন adb root এবং adb shell setenforce 0 তখনই ডিবাগ বৈশিষ্ট্যের অনুমতি দেওয়া।

আরেকটি নিরাপদ বিকল্প হল একটি userdebug_or_eng বিবৃতিতে ডিবাগ অনুমতি সংযুক্ত করা।

নীতি আকার বিস্ফোরণ

ওয়াইল্ডে SEAndroid নীতির বৈশিষ্ট্য ডিভাইস নীতি কাস্টমাইজেশনের বৃদ্ধির একটি সম্পর্কিত প্রবণতা বর্ণনা করে। ডিভাইস-নির্দিষ্ট নীতি একটি ডিভাইসে চলমান সামগ্রিক নীতির 5-10% জন্য দায়ী করা উচিত। 20%+ পরিসরে কাস্টমাইজেশনে প্রায় নিশ্চিতভাবেই বেশি সুবিধাপ্রাপ্ত ডোমেন এবং মৃত নীতি থাকে।

অপ্রয়োজনীয়ভাবে বড় নীতি:

• পলিসিটি র‍্যামডিস্কে বসে এবং কার্নেল মেমরিতে লোড হওয়ার কারণে মেমরিতে ডাবল হিট লাগে।
• বৃহত্তর বুটিমেজের প্রয়োজনে ডিস্কের স্থান নষ্ট করে।
• রানটাইম পলিসি লুকআপ সময় প্রভাবিত করে।

নিম্নলিখিত উদাহরণটি দুটি ডিভাইস দেখায় যেখানে প্রস্তুতকারক-নির্দিষ্ট নীতিতে ডিভাইস নীতির 50% এবং 40% অন্তর্ভুক্ত ছিল৷ নীতির একটি পুনঃলিখন কার্যকারিতার কোন ক্ষতি ছাড়াই যথেষ্ট নিরাপত্তা উন্নতি করেছে, যেমনটি নীচে দেখানো হয়েছে। (AOSP ডিভাইস শামু এবং ফ্লাউন্ডার তুলনা করার জন্য অন্তর্ভুক্ত করা হয়েছে।)

চিত্র 1 । নিরাপত্তা নিরীক্ষার পরে ডিভাইস-নির্দিষ্ট নীতির আকারের তুলনা।

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

dac_override ক্ষমতা প্রদান করুন

একটি dac_override অস্বীকারের অর্থ হল আপত্তিকর প্রক্রিয়াটি ভুল ইউনিক্স ব্যবহারকারী/গ্রুপ/ওয়ার্ল্ড অনুমতি সহ একটি ফাইল অ্যাক্সেস করার চেষ্টা করছে। সঠিক সমাধান প্রায় কখনই dac_override অনুমতি দেয় না। পরিবর্তে ফাইল বা প্রক্রিয়ার ইউনিক্স অনুমতি পরিবর্তন করুন । কিছু ডোমেইন যেমন init , vold , এবং installd এর অন্য প্রসেসের ফাইলগুলি অ্যাক্সেস করার জন্য ইউনিক্স ফাইলের অনুমতিগুলিকে ওভাররাইড করার ক্ষমতা প্রয়োজন। আরও গভীর ব্যাখ্যার জন্য ড্যান ওয়ালশের ব্লগ দেখুন।