SELinux কাস্টমাইজ করুন

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

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

SELinux কাস্টমাইজ করার সময়, মনে রাখবেন:

  • সমস্ত নতুন ডেমনের জন্য SELinux নীতি লিখুন
  • যখনই উপযুক্ত তখন পূর্বনির্ধারিত ডোমেন ব্যবহার করুন
  • একটি init পরিষেবা হিসাবে উদ্ভূত যেকোনো প্রক্রিয়ার জন্য একটি ডোমেন বরাদ্দ করুন
  • নীতি লেখার আগে ম্যাক্রোর সাথে পরিচিত হন
  • AOSP-এ মূল নীতিতে পরিবর্তন জমা দিন

এবং মনে রাখবেন না:

  • বেমানান নীতি তৈরি করুন
  • শেষ ব্যবহারকারী নীতি কাস্টমাইজেশনের অনুমতি দিন
  • MDM নীতি কাস্টমাইজেশনের অনুমতি দিন
  • নীতি লঙ্ঘন করে ব্যবহারকারীদের ভয় দেখান
  • পিছনের দরজা যোগ করুন

নির্দিষ্ট প্রয়োজনীয়তার জন্য অ্যান্ড্রয়েড সামঞ্জস্যতা সংজ্ঞা নথির কার্নেল নিরাপত্তা বৈশিষ্ট্য বিভাগটি দেখুন।

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

  1. সর্বশেষ অ্যান্ড্রয়েড কার্নেল ব্যবহার করুন।
  2. ন্যূনতম সুবিধার নীতি গ্রহণ করুন।
  3. Android এ শুধুমাত্র আপনার নিজস্ব সংযোজন সম্বোধন করুন। ডিফল্ট নীতিটি স্বয়ংক্রিয়ভাবে Android ওপেন সোর্স প্রজেক্ট কোডবেসের সাথে কাজ করে।
  4. সফ্টওয়্যার উপাদানগুলিকে মডিউলগুলিতে ভাগ করে যা একক কাজগুলি পরিচালনা করে।
  5. SELinux নীতিগুলি তৈরি করুন যা এই কাজগুলিকে সম্পর্কহীন ফাংশন থেকে বিচ্ছিন্ন করে।
  6. এই পলিসিগুলিকে *.te ফাইলে (SELinux পলিসি সোর্স ফাইলের এক্সটেনশন) /device/ manufacturer / device-name /sepolicy ডিরেক্টরির মধ্যে রাখুন এবং আপনার বিল্ডে অন্তর্ভুক্ত করতে BOARD_SEPOLICY ভেরিয়েবল ব্যবহার করুন।
  7. নতুন ডোমেইনগুলিকে প্রাথমিকভাবে অনুমতিযোগ্য করুন। এটি ডোমেনের .te ফাইলে একটি অনুমতিমূলক ঘোষণা ব্যবহার করে করা হয়৷
  8. ফলাফল বিশ্লেষণ করুন এবং আপনার ডোমেনের সংজ্ঞা পরিমার্জন করুন।
  9. ইউজারডিবাগ বিল্ডে আর কোনো অস্বীকৃতি উপস্থিত না হলে অনুমতিমূলক ঘোষণাটি সরান।

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

আপনি যখন SELinux কাস্টমাইজ করা শুরু করেন, প্রথমে Android এ আপনার সংযোজন অডিট করুন। আপনি যদি একটি নতুন ফাংশন পরিচালনা করে এমন একটি উপাদান যোগ করে থাকেন, তাহলে নিশ্চিত করুন যে উপাদানটি Android-এর নিরাপত্তা নীতির সাথে সাথে OEM দ্বারা তৈরি করা কোনো সংশ্লিষ্ট নীতি মেনে চলে, এনফোর্সিং মোড চালু করার আগে।

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

উদাহরণ নীতি বিবৃতি

SELinux M4 কম্পিউটার ভাষার উপর ভিত্তি করে এবং তাই সময় বাঁচাতে বিভিন্ন ধরনের ম্যাক্রো সমর্থন করে।

নিম্নলিখিত উদাহরণে, সমস্ত ডোমেনকে /dev/null থেকে পড়তে বা লিখতে এবং /dev/zero থেকে পড়ার অনুমতি দেওয়া হয়েছে।

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

এই একই বিবৃতিটি SELinux *_file_perms ম্যাক্রো (শর্টহ্যান্ড) দিয়ে লেখা যেতে পারে: 

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

উদাহরণ নীতি

এখানে DHCP এর জন্য একটি সম্পূর্ণ উদাহরণ নীতি রয়েছে, যা আমরা নীচে পরীক্ষা করি:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

আসুন উদাহরণটি বিচ্ছিন্ন করা যাক:

প্রথম লাইনে, টাইপ ডিক্লারেশন, DHCP ডেমন বেস সিকিউরিটি পলিসি ( domain ) থেকে উত্তরাধিকার সূত্রে প্রাপ্ত। পূর্ববর্তী বিবৃতি উদাহরণ থেকে, DHCP /dev/null থেকে পড়তে এবং লিখতে পারে।

দ্বিতীয় লাইনে, DHCP একটি অনুমতিমূলক ডোমেন হিসাবে চিহ্নিত করা হয়।

init_daemon_domain(dhcp) লাইনে, নীতিতে বলা হয়েছে DHCP init থেকে তৈরি হয়েছে এবং এটির সাথে যোগাযোগ করার অনুমতি দেওয়া হয়েছে।

net_domain(dhcp) লাইনে, নীতিটি DHCP কে net ডোমেন থেকে সাধারণ নেটওয়ার্ক কার্যকারিতা যেমন TCP প্যাকেট পড়া এবং লেখা, সকেটের মাধ্যমে যোগাযোগ করা এবং DNS অনুরোধ পরিচালনা করার অনুমতি দেয়।

লাইনে allow dhcp proc_net:file write; , নীতিতে বলা হয়েছে DHCP /proc এ নির্দিষ্ট ফাইলগুলিতে লিখতে পারে। এই লাইনটি SELinux-এর সূক্ষ্ম-দানাযুক্ত ফাইল লেবেলিং প্রদর্শন করে। এটি শুধুমাত্র /proc/sys/net অধীনে থাকা ফাইলগুলিতে লেখার অ্যাক্সেস সীমিত করতে proc_net লেবেল ব্যবহার করে।

allow dhcp netd:fd use; অ্যাপগুলিকে কীভাবে একে অপরের সাথে ইন্টারঅ্যাক্ট করার অনুমতি দেওয়া যেতে পারে তা চিত্রিত করে৷ নীতি বলছে DHCP এবং netd ফাইল বর্ণনাকারী, FIFO ফাইল, ডেটাগ্রাম সকেট এবং UNIX স্ট্রিম সকেটের মাধ্যমে একে অপরের সাথে যোগাযোগ করতে পারে। DHCP শুধুমাত্র ডেটাগ্রাম সকেট এবং UNIX স্ট্রিম সকেট থেকে পড়তে এবং লিখতে পারে এবং সেগুলি তৈরি বা খুলতে পারে না।

উপলব্ধ নিয়ন্ত্রণ

ক্লাস অনুমতি
ফাইল
ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton
ডিরেক্টরি
add_name remove_name reparent search rmdir open audit_access execmod
সকেট
ioctl read write create getattr setattr lock relabelfrom relabelto append bind
connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
name_bind
ফাইল সিস্টেম
mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget
প্রক্রিয়া
fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
execstack execheap setkeycreate setsockcreate
নিরাপত্তা
compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy
ক্ষমতা
chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap

আরও

এবং আরো

নিয়ম কখনই অনুমোদন করবেন না

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

নিম্নলিখিত নির্দেশিকাগুলি নির্মাতাদের কাস্টমাইজেশনের সময় neverallow নিয়ম সম্পর্কিত ত্রুটিগুলি এড়াতে সহায়তা করার উদ্দেশ্যে করা হয়েছে৷ এখানে ব্যবহৃত নিয়ম সংখ্যাগুলি Android 5.1 এর সাথে মিলে যায় এবং প্রকাশের মাধ্যমে পরিবর্তন সাপেক্ষে।

নিয়ম 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
ptrace এর জন্য ম্যান পেজ দেখুন। sys_ptrace ক্ষমতা যেকোন প্রসেস ptrace ক্ষমতা প্রদান করে, যা অন্যান্য প্রসেসের উপর অনেক বেশি নিয়ন্ত্রণের অনুমতি দেয় এবং শুধুমাত্র নির্ধারিত সিস্টেমের উপাদানগুলির অন্তর্ভুক্ত হওয়া উচিত, যা নিয়মে বর্ণিত হয়েছে। এই ক্ষমতার প্রয়োজনীয়তা প্রায়শই এমন কিছুর উপস্থিতি নির্দেশ করে যা ব্যবহারকারী-মুখী বিল্ড বা কার্যকারিতার জন্য নয় যা প্রয়োজন হয় না। অপ্রয়োজনীয় উপাদান সরান।

নিয়ম 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
এই নিয়মটি সিস্টেমে স্বেচ্ছাচারী কোড কার্যকর করা রোধ করার উদ্দেশ্যে করা হয়েছে। বিশেষভাবে, এটি দাবি করে যে শুধুমাত্র /system কোড কার্যকর করা হয়, যা যাচাইকৃত বুটের মতো প্রক্রিয়াগুলির জন্য নিরাপত্তা গ্যারান্টিকে ধন্যবাদ দেয়। প্রায়শই, neverallow নিয়মের সাথে কোনো সমস্যার সম্মুখীন হলে সর্বোত্তম সমাধান হল আপত্তিকর কোডটিকে /system পার্টিশনে সরানো।

Android 8.0 এবং উচ্চতর সংস্করণে SEPpolicy কাস্টমাইজ করুন

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

পলিসি প্লেসমেন্ট

Android 7.0 এবং তার আগে, ডিভাইস নির্মাতারা BOARD_SEPOLICY_DIRS এ নীতি যোগ করতে পারে, যার মধ্যে বিভিন্ন ডিভাইসের ধরন জুড়ে AOSP নীতি বাড়ানোর নীতি অন্তর্ভুক্ত। Android 8.0 এবং উচ্চতর সংস্করণে, BOARD_SEPOLICY_DIRS এ একটি নীতি যোগ করলে নীতিটি শুধুমাত্র বিক্রেতার ছবিতে থাকে।

Android 8.0 এবং উচ্চতর সংস্করণে, AOSP-তে নিম্নলিখিত অবস্থানগুলিতে নীতি বিদ্যমান:

  • সিস্টেম/সিপলিসি/পাবলিক। বিক্রেতা-নির্দিষ্ট নীতিতে ব্যবহারের জন্য রপ্তানি করা নীতি অন্তর্ভুক্ত করে। সবকিছু Android 8.0 সামঞ্জস্যপূর্ণ পরিকাঠামোর মধ্যে যায়। পাবলিক পলিসি হল রিলিজ জুড়ে টিকে থাকার জন্য যাতে আপনি আপনার কাস্টমাইজড নীতিতে যেকোনো কিছু /public অন্তর্ভুক্ত করতে পারেন। এই কারণে, /public -এ যে ধরনের নীতি রাখা যেতে পারে তা আরও সীমাবদ্ধ। এই প্ল্যাটফর্মের রপ্তানি নীতি API বিবেচনা করুন: /system এবং /vendor মধ্যে ইন্টারফেসের সাথে সম্পর্কিত যেকোন কিছু এখানে অন্তর্গত।
  • সিস্টেম/সিপলিসি/প্রাইভেট। সিস্টেম ইমেজের কার্যকারিতার জন্য প্রয়োজনীয় নীতি অন্তর্ভুক্ত করে, কিন্তু বিক্রেতার চিত্র নীতির কোন জ্ঞান থাকা উচিত নয়।
  • সিস্টেম/সেপলিসি/বিক্রেতা। উপাদানগুলির জন্য নীতি অন্তর্ভুক্ত করে যেগুলি /vendor মধ্যে যায় কিন্তু মূল প্ল্যাটফর্ম ট্রিতে বিদ্যমান (ডিভাইস-নির্দিষ্ট ডিরেক্টরি নয়)। এটি ডিভাইস এবং গ্লোবাল উপাদানগুলির মধ্যে সিস্টেমের পার্থক্যের একটি নিদর্শন; ধারণাগতভাবে এটি নীচে বর্ণিত ডিভাইস-নির্দিষ্ট নীতির একটি অংশ।
  • ডিভাইস/ manufacturer / device-name /সিপলিসি। ডিভাইস-নির্দিষ্ট নীতি অন্তর্ভুক্ত। এছাড়াও নীতিতে ডিভাইস কাস্টমাইজেশন অন্তর্ভুক্ত করে, যা Android 8.0 এবং উচ্চতর বিক্রেতার চিত্রের উপাদানগুলির জন্য নীতির সাথে মিলে যায়৷

Android 11 এবং উচ্চতর সংস্করণে, system_ext এবং পণ্য পার্টিশনগুলিতে পার্টিশন-নির্দিষ্ট নীতিগুলিও অন্তর্ভুক্ত থাকতে পারে। system_ext এবং পণ্য নীতিগুলিও সরকারী এবং ব্যক্তিগত মধ্যে বিভক্ত, এবং বিক্রেতারা সিস্টেম নীতির মতো system_ext এবং পণ্যের সর্বজনীন নীতিগুলি ব্যবহার করতে পারে।

  • SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS । বিক্রেতা-নির্দিষ্ট নীতিতে ব্যবহারের জন্য রপ্তানি করা নীতি অন্তর্ভুক্ত করে। system_ext পার্টিশনে ইনস্টল করা হয়েছে।
  • SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS । সিস্টেম_এক্সট চিত্রের কার্যকারিতার জন্য প্রয়োজনীয় নীতি অন্তর্ভুক্ত করে, কিন্তু যেটির বিক্রেতার চিত্র নীতির কোন জ্ঞান থাকা উচিত নয়। system_ext পার্টিশনে ইনস্টল করা হয়েছে।
  • PRODUCT_PUBLIC_SEPOLICY_DIRS । বিক্রেতা-নির্দিষ্ট নীতিতে ব্যবহারের জন্য রপ্তানি করা নীতি অন্তর্ভুক্ত করে। পণ্য পার্টিশনে ইনস্টল করা হয়েছে।
  • PRODUCT_PRIVATE_SEPOLICY_DIRS । পণ্যের চিত্রের কার্যকারিতার জন্য প্রয়োজনীয় নীতি অন্তর্ভুক্ত করে, তবে বিক্রেতার চিত্র নীতির কোন জ্ঞান থাকা উচিত নয়। পণ্য পার্টিশনে ইনস্টল করা হয়েছে।
দ্রষ্টব্য: যখন GSI ব্যবহার করা হয়, তখন OEM এর system_ext এবং পণ্য পার্টিশন মাউন্ট করা হবে না। OEM-এর সিস্টেম_এক্সট এবং পণ্য পাবলিক পলিসি ব্যবহার করে বিক্রেতার সেপলিসির নিয়মগুলি NOP হয়ে যায় কারণ OEM-নির্দিষ্ট প্রকারের সংজ্ঞা অনুপস্থিত।
দ্রষ্টব্য: system_ext এবং পণ্য পাবলিক নীতিগুলি ব্যবহার করার সময় অতিরিক্ত সতর্কতা অবলম্বন করুন৷ সর্বজনীন নীতিগুলি system_ext/product এবং বিক্রেতার মধ্যে রপ্তানিকৃত API হিসাবে কাজ করে। অংশীদারদের সামঞ্জস্যের সমস্যাগুলি নিজেরাই পরিচালনা করার কথা।

সমর্থিত নীতি পরিস্থিতি

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

বিক্রেতা-ছবি-শুধুমাত্র এক্সটেনশন

উদাহরণ: ভেন্ডর ইমেজ থেকে vndservicemanager এ একটি নতুন পরিষেবা যোগ করা যা ভেন্ডর ইমেজ থেকে প্রসেস সমর্থন করে।

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

AOSP এর সাথে কাজ করার জন্য বিক্রেতা-ইমেজ সমর্থন

উদাহরণ: একটি নতুন প্রক্রিয়া যুক্ত করা (বিক্রেতা চিত্র থেকে hwservicemanager সাথে নিবন্ধিত) যা একটি AOSP-সংজ্ঞায়িত HAL প্রয়োগ করে।

পূর্ববর্তী অ্যান্ড্রয়েড সংস্করণগুলির সাথে চালু হওয়া ডিভাইসগুলির মতো, device/ manufacturer / device-name /sepolicy তে ডিভাইস-নির্দিষ্ট কাস্টমাইজেশন সম্পাদন করুন। system/sepolicy/public/ এর অংশ হিসাবে রপ্তানি করা নীতি ব্যবহারের জন্য উপলব্ধ, এবং বিক্রেতা নীতির অংশ হিসাবে পাঠানো হয়। পাবলিক পলিসির ধরন এবং বৈশিষ্ট্যগুলি নতুন নিয়মে ব্যবহার করা যেতে পারে যা নতুন বিক্রেতা-নির্দিষ্ট বিটগুলির সাথে মিথস্ক্রিয়া নির্দেশ করে, প্রদত্ত বিধিনিষেধের neverallow দেওয়া সাপেক্ষে। শুধুমাত্র বিক্রেতার ক্ষেত্রে, এখানে নতুন নীতি শুধুমাত্র ফ্রেমওয়ার্ক-ওটিএর অংশ হিসাবে আপডেট করা হবে না এবং রেফারেন্স AOSP সিস্টেম চিত্র সহ একটি ডিভাইসে সম্মিলিত নীতিতে উপস্থিত রয়েছে।

সিস্টেম-ইমেজ-শুধুমাত্র এক্সটেনশন

উদাহরণ: একটি নতুন পরিষেবা যোগ করা (পরিষেবা ব্যবস্থাপকের সাথে নিবন্ধিত) যা শুধুমাত্র সিস্টেম ইমেজ থেকে অন্যান্য প্রক্রিয়া দ্বারা অ্যাক্সেস করা হয়।

system/sepolicy/private এই নীতি যোগ করুন। আপনি একটি অংশীদার সিস্টেম ইমেজে কার্যকারিতা সক্ষম করতে অতিরিক্ত প্রক্রিয়া বা অবজেক্ট যোগ করতে পারেন, যদি সেই নতুন বিটগুলিকে বিক্রেতার ছবিতে নতুন উপাদানগুলির সাথে ইন্টারঅ্যাক্ট করার প্রয়োজন না হয় (বিশেষত, এই ধরনের প্রক্রিয়া বা বস্তুগুলি অবশ্যই বিক্রেতার চিত্রের নীতি ছাড়াই সম্পূর্ণরূপে কাজ করবে) . system/sepolicy/public দ্বারা রপ্তানি করা নীতি এখানে পাওয়া যায় ঠিক যেমন এটি শুধুমাত্র বিক্রেতা-ইমেজ এক্সটেনশনের জন্য। এই নীতিটি সিস্টেম ইমেজের অংশ এবং একটি ফ্রেমওয়ার্ক-কেবল OTA-তে আপডেট করা যেতে পারে, কিন্তু রেফারেন্স AOSP সিস্টেম ইমেজ ব্যবহার করার সময় উপস্থিত থাকবে না।

বিক্রেতা-ইমেজ এক্সটেনশন যা বর্ধিত AOSP উপাদান পরিবেশন করে

উদাহরণ: বর্ধিত ক্লায়েন্টদের দ্বারা ব্যবহারের জন্য একটি নতুন, নন-AOSP HAL যা AOSP সিস্টেম ইমেজে (যেমন একটি বর্ধিত সিস্টেম_সার্ভার) বিদ্যমান।

সিস্টেম এবং বিক্রেতার মধ্যে মিথস্ক্রিয়া জন্য নীতি অবশ্যই বিক্রেতা পার্টিশনে পাঠানো device/ manufacturer / device-name /sepolicy ডিরেক্টরিতে অন্তর্ভুক্ত করতে হবে। এটি রেফারেন্স AOSP ইমেজের সাথে কাজ করার জন্য বিক্রেতা-ইমেজ সমর্থন যোগ করার উপরের দৃশ্যের অনুরূপ, পরিবর্তিত AOSP উপাদানগুলি ছাড়া বাকি সিস্টেম পার্টিশনের সাথে সঠিকভাবে কাজ করার জন্য অতিরিক্ত নীতির প্রয়োজন হতে পারে (যা ততক্ষণ পর্যন্ত ঠিক আছে যতক্ষণ না তারা এখনও থাকে) পাবলিক AOSP টাইপ লেবেল আছে)।

সিস্টেম-ইমেজ-কেবল এক্সটেনশনগুলির সাথে পাবলিক AOSP উপাদানগুলির মিথস্ক্রিয়া করার নীতিটি system/sepolicy/private হওয়া উচিত।

সিস্টেম-ইমেজ এক্সটেনশন যা শুধুমাত্র AOSP ইন্টারফেস অ্যাক্সেস করে

উদাহরণ: একটি নতুন, নন-AOSP সিস্টেম প্রক্রিয়াকে অবশ্যই একটি HAL অ্যাক্সেস করতে হবে যার উপর AOSP নির্ভর করে।

এটি সিস্টেম-ইমেজ-অনলি এক্সটেনশন উদাহরণের অনুরূপ, ব্যতীত নতুন সিস্টেম উপাদানগুলি system/vendor ইন্টারফেস জুড়ে ইন্টারঅ্যাক্ট করতে পারে। নতুন সিস্টেম উপাদানের জন্য নীতি অবশ্যই system/sepolicy/private যেতে হবে, যা গ্রহণযোগ্য যদি এটি system/sepolicy/public -এ AOSP দ্বারা ইতিমধ্যেই প্রতিষ্ঠিত একটি ইন্টারফেসের মাধ্যমে হয় (অর্থাৎ, কার্যকারিতার জন্য প্রয়োজনীয় প্রকার এবং বৈশিষ্ট্য রয়েছে)। যদিও নীতিটি ডিভাইস-নির্দিষ্ট নীতিতে অন্তর্ভুক্ত করা যেতে পারে, তবে এটি শুধুমাত্র ফ্রেমওয়ার্ক আপডেটের ফলে অন্যান্য system/sepolicy/private প্রকার বা পরিবর্তন (যে কোনো নীতি-প্রভাবিত উপায়ে) ব্যবহার করতে অক্ষম হবে। নীতিটি একটি কাঠামো-শুধু OTA-তে পরিবর্তিত হতে পারে, কিন্তু AOSP সিস্টেম ইমেজ ব্যবহার করার সময় উপস্থিত থাকবে না (যাতে নতুন সিস্টেমের উপাদানও থাকবে না)।

বিক্রেতা-ইমেজ এক্সটেনশন যা নতুন সিস্টেম উপাদান পরিবেশন করে

উদাহরণ: AOSP অ্যানালগ ছাড়াই একটি ক্লায়েন্ট প্রক্রিয়ার দ্বারা ব্যবহারের জন্য একটি নতুন, নন-AOSP HAL যোগ করা (এবং এর জন্য এর নিজস্ব ডোমেন প্রয়োজন)।

AOSP-এক্সটেনশনের উদাহরণের মতো, সিস্টেম এবং বিক্রেতার মধ্যে মিথস্ক্রিয়ার জন্য নীতি অবশ্যই বিক্রেতা পার্টিশনে পাঠানো device/ manufacturer / device-name /sepolicy ডিরেক্টরিতে যেতে হবে (নিশ্চিত করার জন্য যে সিস্টেম নীতিতে বিক্রেতা-নির্দিষ্ট বিবরণের কোন জ্ঞান নেই)। আপনি নতুন পাবলিক ধরনের যোগ করতে পারেন যা system/sepolicy/public -এ নীতি প্রসারিত করে; এটি শুধুমাত্র বিদ্যমান AOSP নীতি ছাড়াও করা উচিত, অর্থাৎ AOSP পাবলিক পলিসি অপসারণ করবেন না। নতুন পাবলিক প্রকারগুলি তারপর system/sepolicy/private এবং device/ manufacturer / device-name /sepolicy তে নীতির জন্য ব্যবহার করা যেতে পারে।

মনে রাখবেন যে system/sepolicy/public প্রতিটি সংযোজন একটি নতুন সামঞ্জস্যতার গ্যারান্টি প্রকাশ করে জটিলতা যোগ করে যা একটি ম্যাপিং ফাইলে ট্র্যাক করা আবশ্যক এবং যা অন্যান্য বিধিনিষেধের সাপেক্ষে। system/sepolicy/public -এ শুধুমাত্র নতুন ধরনের এবং সংশ্লিষ্ট অনুমোদিত নিয়মগুলি যোগ করা যেতে পারে; বৈশিষ্ট্য এবং অন্যান্য নীতি বিবৃতি সমর্থিত নয়। উপরন্তু, /vendor নীতিতে বস্তুকে সরাসরি লেবেল করার জন্য নতুন পাবলিক টাইপ ব্যবহার করা যাবে না।

অসমর্থিত নীতি পরিস্থিতি

Android 8.0 এবং উচ্চতর সংস্করণের সাথে লঞ্চ হওয়া ডিভাইসগুলি নিম্নলিখিত নীতি পরিস্থিতি এবং উদাহরণগুলিকে সমর্থন করে না৷

সিস্টেম-ইমেজের অতিরিক্ত এক্সটেনশন যার জন্য ফ্রেমওয়ার্ক-কেবল OTA-এর পরে নতুন বিক্রেতা-ইমেজ উপাদানগুলির অনুমতি প্রয়োজন

উদাহরণ: একটি নতুন নন-AOSP সিস্টেম প্রক্রিয়া, যার নিজস্ব ডোমেন প্রয়োজন, পরবর্তী Android রিলিজে যোগ করা হয়েছে এবং একটি নতুন, নন-AOSP HAL-এ অ্যাক্সেসের প্রয়োজন৷

নতুন (নন-এওএসপি) সিস্টেম এবং বিক্রেতা উপাদানগুলির মিথস্ক্রিয়া অনুরূপ, নতুন সিস্টেমের ধরনটি কেবলমাত্র ওটিএ-র কাঠামোতে চালু করা হয়েছে। যদিও নতুন ধরনটি system/sepolicy/public নীতিতে যোগ করা যেতে পারে, বিদ্যমান বিক্রেতা নীতির নতুন ধরনের সম্পর্কে কোন জ্ঞান নেই কারণ এটি শুধুমাত্র Android 8.0 সিস্টেম পাবলিক পলিসি ট্র্যাক করছে। AOSP একটি অ্যাট্রিবিউটের (উদাহরণস্বরূপ, hal_foo অ্যাট্রিবিউট) মাধ্যমে বিক্রেতা-প্রদত্ত সংস্থানগুলিকে প্রকাশ করে এটি পরিচালনা করে কিন্তু বৈশিষ্ট্য অংশীদার এক্সটেনশনগুলি system/sepolicy/public এ সমর্থিত নয়, এই পদ্ধতিটি ভেন্ডর নীতিতে অনুপলব্ধ৷ পূর্বে বিদ্যমান পাবলিক টাইপ দ্বারা অ্যাক্সেস প্রদান করা আবশ্যক।

উদাহরণ: একটি সিস্টেম প্রক্রিয়ার পরিবর্তন (AOSP বা নন-AOSP) নতুন, নন-AOSP ভেন্ডর কম্পোনেন্টের সাথে কীভাবে ইন্টারঅ্যাক্ট করে তা অবশ্যই পরিবর্তন করতে হবে।

সিস্টেম ইমেজ নীতি নির্দিষ্ট বিক্রেতা কাস্টমাইজেশন জ্ঞান ছাড়া লিখতে হবে. AOSP-তে নির্দিষ্ট ইন্টারফেস সম্পর্কিত নীতি এইভাবে সিস্টেম/সিপলিসি/পাবলিকের বৈশিষ্ট্যগুলির মাধ্যমে প্রকাশ করা হয় যাতে বিক্রেতা নীতি ভবিষ্যতের সিস্টেম নীতিতে অপ্ট-ইন করতে পারে যা এই বৈশিষ্ট্যগুলি ব্যবহার করে। যাইহোক, system/sepolicy/public -এ অ্যাট্রিবিউট এক্সটেনশানগুলি সমর্থিত নয় , তাই সমস্ত নীতি নির্দেশ করে যে কীভাবে সিস্টেমের উপাদানগুলি নতুন বিক্রেতার উপাদানগুলির সাথে ইন্টারঅ্যাক্ট করে (এবং যা AOSP system/sepolicy/public এ ইতিমধ্যে উপস্থিত বৈশিষ্ট্যগুলির দ্বারা পরিচালিত হয় না) অবশ্যই থাকতে হবে device/ manufacturer / device-name /sepolicy । এর মানে হল যে সিস্টেমের ধরনগুলি ফ্রেমওয়ার্ক-কেবল OTA-এর অংশ হিসাবে বিক্রেতার প্রকারগুলিতে অনুমোদিত অ্যাক্সেস পরিবর্তন করতে পারে না।