Android 11-এ, OTA আপডেটগুলি A/B আপডেট বা ভার্চুয়াল A/B আপডেট মেকানিজম ব্যবহার করে, RecoverySystem ক্লাস পদ্ধতির সাথে মিলিতভাবে প্রয়োগ করা যেতে পারে। একটি OTA আপডেট প্রয়োগ করার জন্য একটি ডিভাইস রিবুট করার পরে, রিজুমে-অন-রিবুট (RoR) ডিভাইস শংসাপত্র এনক্রিপ্টেড (CE) স্টোরেজ আনলক করে।
যদিও অংশীদাররা এই প্রক্রিয়াটিকে একটি OTA সিস্টেম বৈশিষ্ট্যের সাথে যুক্ত করতে পারে যা Android 11-এ ডিভাইসটি নিষ্ক্রিয় থাকার প্রত্যাশিত সময়ে আপডেটগুলি প্রয়োগ করে, Android 12-এ অংশীদারদের অতিরিক্ত OTA সিস্টেম বৈশিষ্ট্যের প্রয়োজন নেই৷ RoR প্রক্রিয়া ব্যবহারকারীদের অতিরিক্ত নিরাপত্তা এবং সুবিধা প্রদান করে কারণ ডিভাইস অলস সময়ে আপডেট করা যেতে পারে, যখন Android 12 মাল্টি-ক্লায়েন্ট এবং সার্ভার-ভিত্তিক আপডেট কার্যকারিতা একসাথে ডিভাইস হার্ডওয়্যার-স্তরের নিরাপত্তা প্রদান করে।
যদিও আপনাকে Android 11-এ RoR সমর্থন করার জন্য android.hardware.reboot_escrow বৈশিষ্ট্যটির জন্য ডিভাইসের অনুমতি প্রদান করতে হবে, তবে আপনাকে Android 12 এবং পরবর্তীতে সার্ভার-ভিত্তিক RoR সক্ষম করতে এটি করার দরকার নেই, কারণ তারা HAL ব্যবহার করে না।
পটভূমি
অ্যান্ড্রয়েড 7 থেকে শুরু করে, অ্যান্ড্রয়েড ডাইরেক্ট বুট সমর্থিত, যা ব্যবহারকারীর দ্বারা CE স্টোরেজ আনলক করার আগে একটি ডিভাইসে অ্যাপগুলিকে চালু করতে সক্ষম করে। ডাইরেক্ট বুট সাপোর্টের বাস্তবায়ন ব্যবহারকারীদেরকে বুট করার পরে লক স্ক্রিন নলেজ ফ্যাক্টর (LSKF) প্রবেশ করার আগে আরও ভাল অভিজ্ঞতা প্রদান করে।
OTA আপডেটের পরে রিবুট শুরু হলে RoR একটি ডিভাইসের সমস্ত অ্যাপের CE স্টোরেজকে আনলক করার অনুমতি দেয়, যেগুলি সরাসরি বুট সমর্থন করে না। এই বৈশিষ্ট্যটি ব্যবহারকারীদের তাদের সমস্ত ইনস্টল করা অ্যাপ থেকে বিজ্ঞপ্তি পেতে সক্ষম করে, রিবুট করার পরে।
হুমকি মডেল
RoR এর বাস্তবায়ন নিশ্চিত করতে হবে যে যখন একটি ডিভাইস আক্রমণকারীর হাতে পড়ে, আক্রমণকারীর পক্ষে ব্যবহারকারীর CE-এনক্রিপ্ট করা ডেটা পুনরুদ্ধার করা অত্যন্ত কঠিন, এমনকি ডিভাইসটি চালু থাকলেও, CE স্টোরেজ আনলক করা থাকে এবং ডিভাইসটি আনলক করা থাকে OTA আপডেট পাওয়ার পর ব্যবহারকারী। আক্রমণকারী ব্রডকাস্ট ক্রিপ্টোগ্রাফিক সাইনিং কীগুলিতে অ্যাক্সেস লাভ করলেও ইনসাইডার অ্যাটাক প্রতিরোধ কার্যকর হতে হবে।
বিশেষত, CE স্টোরেজ অবশ্যই এমন আক্রমণকারীর দ্বারা পড়া উচিত নয় যার কাছে ডিভাইসটি শারীরিকভাবে রয়েছে এবং এই ক্ষমতা এবং সীমাবদ্ধতা রয়েছে:
ক্ষমতা
- নির্বিচারে বার্তা সাইন করার জন্য কোনো বিক্রেতা বা কোম্পানির সাইনিং কী ব্যবহার করতে পারেন।
- ডিভাইসটি একটি OTA আপডেট পেতে পারে।
- যেকোন হার্ডওয়্যারের (যেমন একটি অ্যাপ্লিকেশন প্রসেসর, বা ফ্ল্যাশ মেমরি) অপারেশন পরিবর্তন করতে পারে - নীচের সীমাবদ্ধতাগুলিতে বিস্তারিত ছাড়া। (তবে, এই ধরনের পরিবর্তনের মধ্যে অন্তত এক ঘণ্টার বিলম্ব এবং একটি পাওয়ার সাইকেল যা RAM এর বিষয়বস্তু ধ্বংস করে।)
সীমাবদ্ধতা
- টেম্পার-প্রতিরোধী হার্ডওয়্যারের ক্রিয়াকলাপ সংশোধন করতে পারে না (উদাহরণস্বরূপ, একটি টাইটান এম)।
- লাইভ ডিভাইসের RAM পড়তে পারে না।
- ব্যবহারকারীর শংসাপত্র (পিন, প্যাটার্ন, পাসওয়ার্ড) অনুমান করতে পারে না বা অন্যথায় সেগুলি প্রবেশ করাতে পারে না৷
সমাধান
অ্যান্ড্রয়েড 12 RoR আপডেট সিস্টেম অত্যন্ত পরিশীলিত আক্রমণকারীদের বিরুদ্ধে নিরাপত্তা প্রদান করে এবং ডিভাইসে থাকা পাসওয়ার্ড এবং পিনগুলি ডিভাইসে থাকার সময় তা করে—সেগুলি কখনই Google সার্ভারে পাঠানো বা সংরক্ষণ করা হয় না। এটি প্রক্রিয়াটির একটি সংক্ষিপ্ত বিবরণ যা নিশ্চিত করে যে প্রদত্ত সুরক্ষা স্তরগুলি একটি হার্ডওয়্যার-ভিত্তিক, ডিভাইস-স্তরের RoR সিস্টেমের অনুরূপ:
- Android একটি ডিভাইসে সঞ্চিত ডেটাতে ক্রিপ্টোগ্রাফিক সুরক্ষা প্রয়োগ করে৷
- সমস্ত ডেটা বিশ্বস্ত এক্সিকিউশন এনভায়রনমেন্টে (TEE) সংরক্ষিত কী দ্বারা সুরক্ষিত।
- চলমান অপারেটিং সিস্টেমটি ক্রিপ্টোগ্রাফিক প্রমাণীকরণ ( যাচাইকৃত বুট ) পাস করলে TEE শুধুমাত্র কীগুলি প্রকাশ করে।
- Google সার্ভারে চলমান RoR পরিষেবা একটি গোপন তথ্য সংরক্ষণ করে সিই ডেটা সুরক্ষিত করে যা শুধুমাত্র সীমিত সময়ের জন্য পুনরুদ্ধার করা যেতে পারে। এটি অ্যান্ড্রয়েড ইকোসিস্টেম জুড়ে কাজ করে।
- একটি ক্রিপ্টোগ্রাফিক কী, ব্যবহারকারীর পিন দ্বারা সুরক্ষিত, ডিভাইসটি আনলক করতে এবং CE স্টোরেজ ডিক্রিপ্ট করতে ব্যবহৃত হয়।
- যখন রাতারাতি রিবুট নির্ধারিত হয়, তখন Android ব্যবহারকারীকে তাদের পিন লিখতে অনুরোধ করে, তারপর একটি সিন্থেটিক পাসওয়ার্ড (SP) গণনা করে।
- এটি তারপরে SP-কে দুবার এনক্রিপ্ট করে: একবার RAM-এ সংরক্ষিত একটি
K_sদিয়ে, এবং আবার TEE-তে সংরক্ষিতK_kকী দিয়ে। - ডাবল-এনক্রিপ্ট করা SP ডিস্কে সংরক্ষণ করা হয়, এবং SP RAM থেকে মুছে যায়। উভয় কীই নতুনভাবে তৈরি করা হয় এবং শুধুমাত্র একটি রিবুটের জন্য ব্যবহার করা হয়।
- যখন রিবুট করার সময় হয়, তখন Android সার্ভারে
K_sঅর্পণ করে।K_kএর সাথে রসিদটি ডিস্কে সংরক্ষণ করার আগে এনক্রিপ্ট করা হয়। - রিবুট করার পরে, Android রসিদ ডিক্রিপ্ট করতে
K_kব্যবহার করে, তারপরK_sপুনরুদ্ধার করতে সার্ভারে পাঠায়।-
K_kএবংK_sডিস্কে সংরক্ষিত SP ডিক্রিপ্ট করতে ব্যবহৃত হয়। - অ্যান্ড্রয়েড সিই স্টোরেজ আনলক করতে এবং স্বাভাবিক অ্যাপ স্টার্টআপের অনুমতি দিতে SP ব্যবহার করে।
-
K_kএবংK_sবাতিল করা হয়।
-
আপনার ফোনকে সুরক্ষিত রাখে এমন আপডেটগুলি এমন একটি সময়ে ঘটতে পারে যা আপনার জন্য সুবিধাজনক: আপনি যখন ঘুমান।
সিম-পিন রিপ্লে
কিছু শর্তে একটি সিম কার্ডের পিন কোড একটি ক্যাশে থেকে যাচাই করা হয়, একটি প্রক্রিয়া যাকে সিম-পিন রিপ্লে বলা হয়।
একটি সক্ষম পিন সহ একটি সিম কার্ডকে অবশ্যই সেলুলার সংযোগ পুনরুদ্ধার করতে (ফোন কল, এসএমএস বার্তা এবং ডেটা পরিষেবাগুলির জন্য প্রয়োজনীয়) একটি অনুপস্থিত রিবুট করার পরে একটি বিজোড় পিন কোড যাচাইকরণ (একটি সিম-পিন রিপ্লে) করতে হবে৷ সিম পিন এবং এর সাথে মিলে যাওয়া সিম কার্ডের তথ্য (আইসিসিআইডি এবং সিম স্লট নম্বর) নিরাপদে একত্রে সংরক্ষণ করা হয়। সংরক্ষিত পিনটি পুনরুদ্ধার করা যেতে পারে এবং শুধুমাত্র একটি সফল অনুপস্থিত রিবুট করার পরেই যাচাইয়ের জন্য ব্যবহার করা যেতে পারে। ডিভাইসটি সুরক্ষিত থাকলে, LSKF দ্বারা সুরক্ষিত কীগুলির সাথে সিম পিন সংরক্ষণ করা হয়। যদি সিমের পিন সক্রিয় থাকে, তাহলে RoR সার্ভারের সাথে ইন্টারঅ্যাকশনের জন্য OTA আপডেট এবং সার্ভার-ভিত্তিক RoR এর জন্য একটি ওয়াইফাই সংযোগ প্রয়োজন , যা রিবুট করার পরে মৌলিক কার্যকারিতা (সেলুলার সংযোগ সহ) নিশ্চিত করে৷
প্রতিবার ব্যবহারকারী সফলভাবে সক্ষম, যাচাই বা সংশোধন করার সময় সিম পিনটি পুনরায় এনক্রিপ্ট করা এবং সংরক্ষণ করা হয়। নিম্নলিখিতগুলির মধ্যে যে কোনও একটি ঘটলে সিম পিনটি বাতিল করা হয়:
- সিম সরানো বা রিসেট করা হয়েছে।
- ব্যবহারকারী পিন নিষ্ক্রিয় করে।
- একটি অ-RoR-প্রবর্তিত রিবুট ঘটেছে।
সংরক্ষিত সিম পিন শুধুমাত্র একবার ব্যবহার করা যেতে পারে RoR-ইনিশিয়েটেড রিবুট করার পরে, এবং শুধুমাত্র খুব অল্প সময়ের জন্য (20 সেকেন্ড)- যদি সিম কার্ডের বিবরণ মিলে যায়। সঞ্চিত সিম পিন কখনই TelephonyManager অ্যাপ ছেড়ে যায় না এবং এটি বাহ্যিক মডিউল দ্বারা পুনরুদ্ধার করা যায় না।
বাস্তবায়ন নির্দেশিকা
অ্যান্ড্রয়েড 12-এ, মাল্টি-ক্লায়েন্ট এবং সার্ভার-ভিত্তিক RoR ফাংশনগুলি যখন অংশীদাররা OTA আপডেটগুলি পুশ করে তখন তাদের একটি হালকা লোড প্রদান করে। প্রয়োজনীয় আপডেটগুলি সুবিধাজনক ডিভাইস ডাউনটাইমের সময় ঘটতে পারে, যেমন নির্দিষ্ট ঘুমের সময়।
এই সময়ের মধ্যে ওটিএ আপডেটগুলি যাতে ব্যবহারকারীদের বাধা না দেয় তা নিশ্চিত করতে, হালকা নির্গমন কমাতে ডার্ক মোড ব্যবহার করুন। এটি করার জন্য, ডিভাইস বুটলোডারকে স্ট্রিং কারণ unattended অনুসন্ধান করতে দিন। unattended true হলে, ডিভাইসটিকে ডার্ক মোডে রাখুন। মনে রাখবেন যে শব্দ এবং আলো নির্গমন প্রশমিত করা প্রতিটি OEM এর দায়িত্ব।
আপনি যদি হয় Android 12-এ আপগ্রেড করছেন বা Android 12 ডিভাইস চালু করছেন, তাহলে নতুন RoR কার্যকারিতা বাস্তবায়নের জন্য আপনাকে কিছু করতে হবে না।
মাল্টি-ক্লায়েন্ট প্রবাহে একটি নতুন কল আছে, isPreparedForUnattendedUpdate , নীচে দেখানো হয়েছে:
@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)
আপনার এটি বাস্তবায়ন করার দরকার নেই, কারণ Android 12 হিসাবে HAL বাতিল করা হয়েছে।
টেলিফোনি ম্যানেজার
Android 12-এ রিবুট আসন্ন হলে OTA ক্লায়েন্ট TelephonyManager সিস্টেম API ব্যবহার করে৷ এই API সমস্ত ক্যাশে করা পিন কোডগুলিকে AVAILABLE অবস্থা থেকে REBOOT_READY অবস্থায় নিয়ে যায়৷ TelephonyManager সিস্টেম API বিদ্যমান REBOOT ম্যানিফেস্ট অনুমতি দ্বারা সুরক্ষিত।
/**
* The unattended reboot was prepared successfully.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_SUCCESS = 0;
/**
* The unattended reboot was prepared, but the user will need to manually
* enter the PIN code of at least one SIM card present in the device.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED = 1;
/**
* The unattended reboot was not prepared due to generic error.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_ERROR = 2;
/** @hide */
@Retention(RetentionPolicy.SOURCE)
@IntDef(prefix = {"PREPARE_UNATTENDED_REBOOT_"},
value = {
PREPARE_UNATTENDED_REBOOT_SUCCESS,
PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED,
PREPARE_UNATTENDED_REBOOT_ERROR
})
public @interface PrepareUnattendedRebootResult {}
/**
* Prepare TelephonyManager for an unattended reboot. The reboot is
* required to be done shortly after the API is invoked.
*
* Requires system privileges.
*
* <p>Requires Permission:
* {@link android.Manifest.permission#REBOOT}
*
* @return {@link #PREPARE_UNATTENDED_REBOOT_SUCCESS} in case of success.
* {@link #PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED} if the device contains
* at least one SIM card for which the user needs to manually enter the PIN
* code after the reboot. {@link #PREPARE_UNATTENDED_REBOOT_ERROR} in case
* of error.
* @hide
*/
@SystemApi
@RequiresPermission(android.Manifest.permission.REBOOT)
@PrepareUnattendedRebootResult
public int prepareForUnattendedReboot()
TelephonyManager সিস্টেম API সুবিধাপ্রাপ্ত APK ব্যবহার করে।
পরীক্ষামূলক
নতুন API পরীক্ষা করতে, এই কমান্ডটি চালান:
adb shell cmd phone unattended-reboot
এই কমান্ডটি তখনই কাজ করে যখন শেল রুট ( adb root ) হিসাবে চলছে।
শুধুমাত্র Android 11
এই পৃষ্ঠার বাকি অংশ Android 11-এ প্রযোজ্য।
জুলাই 2020 অনুযায়ী, RoR HAL এর বাস্তবায়ন দুটি বিভাগে পড়ে:
- যদি SoC হার্ডওয়্যার রিবুট জুড়ে RAM স্থিরতা সমর্থন করে, তাহলে OEMগুলি AOSP ( ডিফল্ট RAM এসক্রো ) এ ডিফল্ট বাস্তবায়ন ব্যবহার করতে পারে।
- যদি ডিভাইস হার্ডওয়্যার বা SoC একটি সুরক্ষিত হার্ডওয়্যার এনক্লেভ সমর্থন করে (নিজস্ব RAM এবং ROM সহ একটি পৃথক সুরক্ষা কপ্রসেসর), অতিরিক্তভাবে এটি অবশ্যই নিম্নলিখিতগুলি করতে হবে:
- একটি প্রধান CPU রিবুট সনাক্ত করতে সক্ষম হন।
- একটি হার্ডওয়্যার টাইমার উৎস আছে যা রিবুট জুড়ে টিকে থাকে। অর্থাৎ, এনক্লেভ অবশ্যই রিবুট সনাক্ত করতে সক্ষম হবে এবং রিবুট করার আগে একটি টাইমার সেটের মেয়াদ শেষ হবে।
- এনক্লেভ RAM/ROM-এ একটি এসক্রোওয়াড কী সংরক্ষণ করতে সহায়তা করে যাতে এটি অফলাইন আক্রমণে পুনরুদ্ধার করা যায় না। এটিকে অবশ্যই RoR কী এমনভাবে সংরক্ষণ করতে হবে যা অভ্যন্তরীণ ব্যক্তি বা আক্রমণকারীদের পক্ষে এটি পুনরুদ্ধার করা অসম্ভব করে তোলে।
ডিফল্ট RAM এসক্রো
AOSP-এর RAM স্থিরতা ব্যবহার করে RoR HAL-এর একটি বাস্তবায়ন রয়েছে। এটি কাজ করার জন্য, OEMগুলিকে নিশ্চিত করতে হবে যে তাদের SoC গুলি রিবুট জুড়ে RAM স্থিরতা সমর্থন করে৷ কিছু SoC একটি রিবুট জুড়ে RAM বিষয়বস্তু বজায় রাখতে অক্ষম, তাই OEM-কে এই ডিফল্ট HAL সক্ষম করার আগে তাদের SoC অংশীদারদের সাথে পরামর্শ করার পরামর্শ দেওয়া হচ্ছে। নিম্নলিখিত বিভাগে এর জন্য ক্যানোনিকাল রেফারেন্স।
RoR ব্যবহার করে OTA আপডেটের প্রবাহ
ফোনের OTA ক্লায়েন্ট অ্যাপে অবশ্যই Manifest.permission.REBOOT এবং Manifest.permission.RECOVERY অনুমতি থাকতে হবে RoR বাস্তবায়নের জন্য প্রয়োজনীয় পদ্ধতিতে কল করার জন্য। সেই পূর্বশর্তের সাথে, একটি আপডেটের প্রবাহ এই পদক্ষেপগুলি অনুসরণ করে:
- OTA ক্লায়েন্ট অ্যাপ আপডেট ডাউনলোড করে।
- OTA ক্লায়েন্ট অ্যাপ
RecoverySystem#prepareForUnattendedUpdateএ কল করে যা পরবর্তী আনলকের সময় ব্যবহারকারীকে তাদের পিন, প্যাটার্ন বা পাসওয়ার্ডের জন্য লক স্ক্রিনে অনুরোধ জানানোর জন্য ট্রিগার করে। - ব্যবহারকারী লকস্ক্রীনে ডিভাইসটি আনলক করে এবং ডিভাইসটি আপডেটটি প্রয়োগ করার জন্য প্রস্তুত।
- OTA ক্লায়েন্ট অ্যাপ
RecoverySystem#rebootAndApplyএ কল করে, যা অবিলম্বে একটি রিবুট ট্রিগার করে।
এই প্রবাহের শেষে, ডিভাইসটি রিবুট হয় এবং RoR প্রক্রিয়া শংসাপত্র এনক্রিপ্ট করা (CE) স্টোরেজ আনলক করে। অ্যাপ্লিকেশানগুলিতে, এটি একটি সাধারণ ব্যবহারকারীর আনলক হিসাবে প্রদর্শিত হয়, তাই তারা ACTION_LOCKED_BOOT_COMPLETED এবং ACTION_BOOT_COMPLETED এর মতো সমস্ত সংকেত গ্রহণ করে যা তারা সাধারণত করে।
পণ্য কনফিগারেশন পরিবর্তন করুন
অ্যান্ড্রয়েড 11-এ RoR বৈশিষ্ট্য সমর্থনকারী হিসাবে চিহ্নিত একটি পণ্যে অবশ্যই RebootEscrow HAL এর বাস্তবায়ন অন্তর্ভুক্ত করতে হবে এবং বৈশিষ্ট্য চিহ্নিতকারী XML ফাইল অন্তর্ভুক্ত করতে হবে। ডিফল্ট বাস্তবায়নটি উষ্ণ রিবুট ব্যবহার করে এমন ডিভাইসগুলিতে ভাল কাজ করে (যখন রিবুট করার সময় DRAM-এর পাওয়ার চালু থাকে)।
এসক্রো বৈশিষ্ট্য মার্কার রিবুট করুন
বৈশিষ্ট্য চিহ্নিতকারী অবশ্যই উপস্থিত থাকতে হবে:
PRODUCT_COPY_FILES += \
frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml
ডিফল্ট রিবুট এসক্রো HAL বাস্তবায়ন
ডিফল্ট বাস্তবায়ন ব্যবহার করতে, আপনাকে অবশ্যই 65536 (0x10000) বাইট সংরক্ষণ করতে হবে। এই বাইটগুলিকে কখনই অ-উদ্বায়ী সঞ্চয়স্থানে লিখবেন না যাতে নিরাপত্তা বৈশিষ্ট্যগুলি বজায় থাকে।
লিনাক্স কার্নেল ডিভাইস ট্রি পরিবর্তন
লিনাক্স কার্নেলের ডিভাইস ট্রিতে, আপনাকে অবশ্যই একটি pmem অঞ্চলের জন্য মেমরি সংরক্ষণ করতে হবে। নিম্নলিখিত উদাহরণ দেখায় 0x50000000 সংরক্ষিত হচ্ছে:
reserved-memory {
my_reservation@0x50000000 {
no-map;
reg = <0x50000000 0x10000>;
}
}
reboot_escrow@0 {
compatible = "pmem-region";
reg = <0x50000000 0x10000>;
};
আপনার ব্লক ডিরেক্টরিতে /dev/block/pmem0 (যেমন pmem1 বা pmem2 ) নামের একটি নতুন ডিভাইস আছে কিনা তা যাচাই করুন।
Device.mk পরিবর্তন
ধরে নিচ্ছি যে পূর্ববর্তী ধাপ থেকে আপনার নতুন ডিভাইসটির নাম pmem0 , আপনাকে অবশ্যই নিশ্চিত করতে হবে যে নিম্নলিখিত নতুন এন্ট্রিগুলি vendor/<oem>/<product>/device.mk এ যোগ করা হয়েছে:
# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
android.hardware.rebootescrow-service.default
SELinux নিয়ম
ডিভাইসের file_contexts এই নতুন এন্ট্রি যোগ করুন:
/dev/block/pmem0 u:object_r:rebootescrow_device:s0
/vendor/bin/hw/android\.hardware\.rebootescrow-service\.default u:object_r:hal_rebootescrow_default_exec:s0