macOS တွင် လုပ်ငန်းစဉ်များနှင့် kernel extension များကို မည်သို့ကာကွယ်မည်နည်း။

မင်္ဂလာပါ Habr။ ဒီနေ့ macOS မှာ တိုက်ခိုက်သူတွေရဲ့ တိုက်ခိုက်မှုတွေကနေ လုပ်ငန်းစဉ်တွေကို ဘယ်လိုကာကွယ်နိုင်မလဲဆိုတာကို ဆွေးနွေးချင်ပါတယ်။ ဥပမာအားဖြင့်၊ ၎င်းသည် antivirus သို့မဟုတ် backup စနစ်အတွက် အသုံးဝင်သည်၊ အထူးသဖြင့် macOS အောက်တွင် လုပ်ငန်းစဉ်တစ်ခုကို "သတ်ရန်" နည်းလမ်းများစွာရှိသောကြောင့်ဖြစ်သည်။ ဤအကြောင်းနှင့် အကာအကွယ်နည်းလမ်းများကို အောက်တွင် ဖတ်ရှုပါ။

လုပ်ငန်းစဉ်တစ်ခုကို "သတ်" ရန်ဂန္ထဝင်နည်းလမ်း

လုပ်ငန်းစဉ်တစ်ခုကို “သတ်ပစ်ရန်” လူသိများသောနည်းလမ်းမှာ လုပ်ငန်းစဉ်သို့ SIGKILL အချက်ပြမှုတစ်ခု ပေးပို့ခြင်းဖြစ်သည်။ bash ဖြင့် သတ်ရန် standard "kill -SIGKILL PID" သို့မဟုတ် "pkill -9 NAME" ဟုခေါ်ဆိုနိုင်ပါသည်။ "kill" command ကို UNIX လက်ထက်ကတည်းက သိရှိထားပြီး macOS တွင်သာမက အခြားသော UNIX ကဲ့သို့သော စနစ်များတွင်လည်း ရနိုင်ပါသည်။

UNIX နှင့်တူသောစနစ်များတွင်ကဲ့သို့ပင်၊ macOS သည် SIGKILL နှင့် SIGSTOP နှစ်ခုမှလွဲ၍ လုပ်ငန်းစဉ်တစ်ခုသို့ မည်သည့်အချက်ပြမှုများကို ကြားဖြတ်နိုင်စေမည်ဖြစ်သည်။ ဤဆောင်းပါးသည် ဖြစ်စဉ်ကို သေစေသည့်အချက်အဖြစ် SIGKILL အချက်ပြမှုအပေါ် အဓိကအာရုံစိုက်ပါမည်။

macOS အထူးများ

macOS တွင်၊ XNU kernel ရှိ kill system call သည် psignal(SIGKILL,...) function ကိုခေါ်ဆိုသည်။ psignal လုပ်ဆောင်ချက်ဖြင့် userspace တွင် အခြားအသုံးပြုသူ လုပ်ဆောင်ချက်များကို ကြည့်ရအောင်။ kernel ၏အတွင်းပိုင်းယန္တရားများရှိ psignal လုပ်ဆောင်ချက်ကို ဖယ်ရှားလိုက်ကြပါစို့ (အသေးအဖွဲမဟုတ်သော်လည်း ၎င်းတို့ကို အခြားဆောင်းပါးတစ်ခုအတွက် ချန်ထားခဲ့ပါမည် 🙂 - လက်မှတ်အတည်ပြုခြင်း၊ မှတ်ဉာဏ်အမှားအယွင်းများ၊ ကိုင်တွယ်ဖြေရှင်းခြင်း/ရပ်စဲခြင်း၊ ဖိုင်ကာကွယ်ရေးချိုးဖောက်မှုများ၊ စသည်တို့

လုပ်ဆောင်ချက်နှင့် သက်ဆိုင်ရာ စနစ်ခေါ်ဆိုမှုဖြင့် ပြန်လည်သုံးသပ်မှုကို စတင်ကြပါစို့ terminate_with_payload. classic kill call အပြင်၊ macOS operating system နှင့် BSD တွင်မတွေ့ရသော အခြားနည်းလမ်းတစ်ခုရှိသည်ကိုတွေ့နိုင်သည်။ စနစ်ခေါ်ဆိုမှုနှစ်ခုလုံး၏ လည်ပတ်မှုအခြေခံမူများသည်လည်း အလားတူပင်ဖြစ်သည်။ ၎င်းတို့သည် kernel function psignal သို့ တိုက်ရိုက်ခေါ်ဆိုမှုများဖြစ်သည်။ လုပ်ငန်းစဉ်တစ်ခုကို မသတ်မီတွင်၊ "cansignal" စစ်ဆေးခြင်းကို လုပ်ဆောင်သည် - လုပ်ငန်းစဉ်သည် အခြားလုပ်ငန်းစဉ်သို့ အချက်ပြမှုတစ်ခု ပေးပို့နိုင်ခြင်း ရှိ၊ မရှိ၊ ဥပမာ၊ စနစ်လုပ်ငန်းစဉ်များကို သတ်ပစ်ရန် မည်သည့်အပလီကေးရှင်းကိုမဆို စနစ်က ခွင့်မပြုပါ။

static int
terminate_with_payload_internal(struct proc *cur_proc, int target_pid, uint32_t reason_namespace,
				uint64_t reason_code, user_addr_t payload, uint32_t payload_size,
				user_addr_t reason_string, uint64_t reason_flags)
{
...
	target_proc = proc_find(target_pid);
...
	if (!cansignal(cur_proc, cur_cred, target_proc, SIGKILL)) {
		proc_rele(target_proc);
		return EPERM;
	}
...
	if (target_pid == cur_proc->p_pid) {
		/*
		 * psignal_thread_with_reason() will pend a SIGKILL on the specified thread or
		 * return if the thread and/or task are already terminating. Either way, the
		 * current thread won't return to userspace.
		 */
		psignal_thread_with_reason(target_proc, current_thread(), SIGKILL, signal_reason);
	} else {
		psignal_with_reason(target_proc, SIGKILL, signal_reason);
	}
...
}

ပစ်လွှတ်လိုက်သည်။

system startup တွင် daemons ဖန်တီးရန်နှင့် ၎င်းတို့၏ သက်တမ်းကို ထိန်းချုပ်ရန် စံနည်းလမ်းကို စတင်လိုက်ပြီဖြစ်သည်။ အရင်းအမြစ်များသည် macOS 10.10 အထိ launchctl ဗားရှင်းဟောင်းအတွက်ဖြစ်ပြီး၊ ကုဒ်နမူနာများကို သရုပ်ဖော်ရန်အတွက် ပံ့ပိုးပေးထားကြောင်း ကျေးဇူးပြု၍ သတိပြုပါ။ ခေတ်မီ launchctl သည် XPC မှတစ်ဆင့် launchd signals များပေးပို့သည်၊ launchctl logic ကို ၎င်းသို့ ရွှေ့ထားသည်။

အပလီကေးရှင်းများကို မည်ကဲ့သို့ ရပ်တန့်ထားသည်ကို ကြည့်ကြပါစို့။ SIGTERM အချက်ပြမှုကို မပို့မီ၊ အပလီကေးရှင်းသည် “proc_terminate” စနစ်ခေါ်ဆိုမှုကို အသုံးပြု၍ ရပ်တန့်ရန် ကြိုးပမ်းခဲ့သည်။

<launchctl src/core.c>
...
	error = proc_terminate(j->p, &sig);
	if (error) {
		job_log(j, LOG_ERR | LOG_CONSOLE, "Could not terminate job: %d: %s", error, strerror(error));
		job_log(j, LOG_NOTICE | LOG_CONSOLE, "Using fallback option to terminate job...");
		error = kill2(j->p, SIGTERM);
		if (error) {
			job_log(j, LOG_ERR, "Could not signal job: %d: %s", error, strerror(error));
		} 
...
<>

အဖုံးအောက်တွင်၊ proc_terminate သည် ၎င်း၏အမည်ရှိသော်လည်း၊ SIGTERM ဖြင့် psignal ကိုသာမက SIGKILL ကိုပါ ပေးပို့နိုင်ပါသည်။

Indirect Kill - အရင်းအမြစ်ကန့်သတ်ချက်

အခြားစနစ်ခေါ်ဆိုမှုတွင် ပိုမိုစိတ်ဝင်စားစရာကောင်းသည့် ကိစ္စရပ်ကို တွေ့နိုင်ပါသည်။ လုပ်ငန်းစဉ်_မူဝါဒ. ဤစနစ်ခေါ်ဆိုမှု၏ ယေဘူယျအသုံးပြုမှုသည် CPU အချိန်နှင့် မှတ်ဉာဏ်ခွဲတမ်းများကို ကန့်သတ်ရန် အညွှန်းကိန်းတစ်ခုအတွက် ကဲ့သို့သော အပလီကေးရှင်းရင်းမြစ်များကို ကန့်သတ်ရန်ဖြစ်ပြီး၊ သို့မှသာ စနစ်သည် ဖိုင်သိမ်းဆည်းခြင်းလုပ်ငန်းများ သိသိသာသာ နှေးကွေးသွားခြင်းမရှိစေရန်ဖြစ်သည်။ အပလီကေးရှင်းတစ်ခုသည် ၎င်း၏ရင်းမြစ်ကန့်သတ်ချက်သို့ရောက်ရှိပါက၊ proc_apply_resource_actions လုပ်ဆောင်ချက်များမှ တွေ့မြင်နိုင်သကဲ့သို့၊ SIGKILL အချက်ပြမှုကို လုပ်ငန်းစဉ်သို့ ပေးပို့မည်ဖြစ်သည်။

ဤစနစ်ခေါ်ဆိုမှုသည် လုပ်ငန်းစဉ်တစ်ခုအား သတ်ပစ်နိုင်သော်လည်း၊ စနစ်သည် စနစ်ခေါ်ဆိုမှုခေါ်ဆိုသည့် လုပ်ငန်းစဉ်၏အခွင့်အရေးများကို လုံလောက်စွာ မစစ်ဆေးနိုင်ခဲ့ပါ။ တကယ်စစ်တယ်။ ရှိခဲ့သည်။၊ သို့သော် ဤအခြေအနေအား ကျော်လွှားရန် အစားထိုးအလံ PROC_POLICY_ACTION_SET ကို အသုံးပြုရန် လုံလောက်ပါသည်။

ထို့ကြောင့် သင်သည် အပလီကေးရှင်း၏ CPU သုံးစွဲမှုခွဲတမ်းကို "ကန့်သတ်" ထားလျှင် (ဥပမာ၊ 1 ns သာလည်ပတ်ခွင့်ပြုသည်) ဆိုလျှင် သင်သည် စနစ်အတွင်းရှိ မည်သည့်လုပ်ငန်းစဉ်ကိုမဆို သတ်ပစ်နိုင်သည်။ ထို့ကြောင့်၊ malware သည် antivirus လုပ်ငန်းစဉ်အပါအဝင် system ရှိ မည်သည့်လုပ်ငန်းစဉ်ကိုမဆို သတ်ပစ်နိုင်သည်။ ထို့အပြင် စိတ်ဝင်စားစရာကောင်းသည်မှာ pid 1 (launchctl) ဖြင့် လုပ်ငန်းစဉ်ကို သတ်သည့်အခါ ဖြစ်ပေါ်လာသည့် အကျိုးသက်ရောက်မှု - SIGKILL အချက်ပြမှုကို လုပ်ဆောင်သည့်အခါ kernel အထိတ်တလန့်ဖြစ်ခြင်း :)

ပြဿနာကို ဘယ်လိုဖြေရှင်းမလဲ။

လုပ်ငန်းစဉ်ကို အသတ်မခံရအောင် ကာကွယ်ရန် အရိုးရှင်းဆုံးနည်းလမ်းမှာ စနစ်ခေါ်ဆိုမှုဇယားရှိ function pointer ကို အစားထိုးခြင်းဖြစ်သည်။ ကံမကောင်းစွာဖြင့်၊ ဤနည်းလမ်းသည် အကြောင်းအမျိုးမျိုးကြောင့် အသေးအဖွဲမဟုတ်ပေ။

ပထမဦးစွာ၊ sysent ၏မှတ်ဉာဏ်တည်နေရာကိုထိန်းချုပ်သည့်သင်္ကေတသည် XNU kernel သင်္ကေတအတွက်သီးသန့်မဟုတ်သော်လည်း kernel သင်္ကေတများတွင်မတွေ့နိုင်ပါ။ လုပ်ဆောင်ချက်ကို အင်တိုက်အားတိုက် ခွဲထုတ်ခြင်းနှင့် ၎င်းရှိ ညွှန်ပြချက်ကို ရှာဖွေခြင်းကဲ့သို့သော ရူရစ်စတီကျသော ရှာဖွေရေးနည်းလမ်းများကို သင်အသုံးပြုရမည်ဖြစ်ပါသည်။

ဒုတိယအနေဖြင့်၊ ဇယားရှိ entry များ၏ဖွဲ့စည်းပုံသည် kernel ပြုစုထားသောအလံများပေါ်တွင်မူတည်သည်။ CONFIG_REQUIRES_U32_MUNGING အလံကို ကြေညာပါက၊ ဖွဲ့စည်းပုံ၏ အရွယ်အစားကို ပြောင်းလဲသွားမည် - အပိုအကွက်တစ်ခု ထပ်ထည့်ပါမည်။ sy_arg_munge32. မည်သည့် kernel အလံကို စုစည်းထားသည်ကို ဆုံးဖြတ်ရန် နောက်ထပ်စစ်ဆေးမှုတစ်ခု လုပ်ဆောင်ရန် လိုအပ်သည်၊ သို့မဟုတ် တနည်းအားဖြင့် သိထားသည့်အရာများနှင့် ပတ်သက်သည့် function pointers များကို စစ်ဆေးရန် လိုအပ်ပါသည်။

struct sysent {         /* system call table */
        sy_call_t       *sy_call;       /* implementing function */
#if CONFIG_REQUIRES_U32_MUNGING || (__arm__ && (__BIGGEST_ALIGNMENT__ > 4))
        sy_munge_t      *sy_arg_munge32; /* system call arguments munger for 32-bit process */
#endif
        int32_t         sy_return_type; /* system call return types */
        int16_t         sy_narg;        /* number of args */
        uint16_t        sy_arg_bytes;   /* Total size of arguments in bytes for
                                         * 32-bit system calls
                                         */
};

ကံကောင်းထောက်မစွာ၊ ခေတ်မီ macOS ဗားရှင်းများတွင် Apple သည် လုပ်ငန်းစဉ်များနှင့် လုပ်ဆောင်ရန်အတွက် API အသစ်ကို ပံ့ပိုးပေးပါသည်။ Endpoint Security API သည် သုံးစွဲသူများအား အခြားလုပ်ငန်းစဉ်များသို့ တောင်းဆိုမှုများစွာကို ခွင့်ပြုပေးသည်။ ထို့ကြောင့်၊ သင်သည် အထက်ဖော်ပြပါ API ကို အသုံးပြု၍ SIGKILL အချက်ပြမှုအပါအဝင် လုပ်ငန်းစဉ်များအတွက် မည်သည့်အချက်ပြမှုများကိုမဆို ပိတ်ဆို့နိုင်သည်။

#include <bsm/libbsm.h>
#include <EndpointSecurity/EndpointSecurity.h>
#include <unistd.h>

int main(int argc, const char * argv[]) {
    es_client_t* cli = nullptr;
    {
        auto res = es_new_client(&cli, ^(es_client_t * client, const es_message_t * message) {
            switch (message->event_type) {
                case ES_EVENT_TYPE_AUTH_SIGNAL:
                {
                    auto& msg = message->event.signal;
                    auto target = msg.target;
                    auto& token = target->audit_token;
                    auto pid = audit_token_to_pid(token);
                    printf("signal '%d' sent to pid '%d'n", msg.sig, pid);
                    es_respond_auth_result(client, message, pid == getpid() ? ES_AUTH_RESULT_DENY : ES_AUTH_RESULT_ALLOW, false);
                }
                    break;
                default:
                    break;
            }
        });
    }

    {
        es_event_type_t evs[] = { ES_EVENT_TYPE_AUTH_SIGNAL };
        es_subscribe(cli, evs, sizeof(evs) / sizeof(*evs));
    }

    printf("%dn", getpid());
    sleep(60); // could be replaced with other waiting primitive

    es_unsubscribe_all(cli);
    es_delete_client(cli);

    return 0;
}

အလားတူ၊ အချက်ပြကာကွယ်မှုနည်းလမ်း (မူဝါဒ proc_check_signal) ကိုပံ့ပိုးပေးသည့် kernel တွင် MAC မူဝါဒကို မှတ်ပုံတင်နိုင်သော်လည်း API ကိုတရားဝင်ပံ့ပိုးမထားပါ။

Kernel တိုးချဲ့မှုကာကွယ်မှု

စနစ်အတွင်းရှိ လုပ်ငန်းစဉ်များကို ကာကွယ်ခြင်းအပြင် kernel extension ကိုယ်တိုင် (kext) ကို ကာကွယ်ရန်လည်း လိုအပ်ပါသည်။ macOS သည် IOKit စက်ပစ္စည်းဒရိုင်ဘာများကို အလွယ်တကူတီထွင်နိုင်ရန် developer များအတွက် framework တစ်ခုပေးထားသည်။ စက်ပစ္စည်းများနှင့် အလုပ်လုပ်ရန် ကိရိယာများ ပံ့ပိုးပေးသည့်အပြင်၊ IOKit သည် C++ အတန်းများကို အသုံးပြု၍ ဒရိုက်ဘာ stacking အတွက် နည်းလမ်းများကို ပေးပါသည်။ အသုံးပြုသူနေရာရှိ အပလီကေးရှင်းတစ်ခုသည် kernel-userspace ဆက်ဆံရေးကို ထူထောင်ရန် အတန်း၏ စာရင်းသွင်းထားသော စံနမူနာတစ်ခုကို “ရှာ” နိုင်မည်ဖြစ်သည်။

စနစ်ရှိ class instance အရေအတွက်ကို သိရှိရန် ioclasscount utility ရှိပါသည်။

my_kext_ioservice = 1
my_kext_iouserclient = 1

driver stack ဖြင့် စာရင်းသွင်းလိုသော မည်သည့် kernel extension သည် IOService မှ အမွေဆက်ခံသော class တစ်ခုကို ကြေညာရမည်ဖြစ်ပြီး ဥပမာ၊ ဥပမာ my_kext_ioservice သည် ဤကိစ္စရပ်တွင် ဖြစ်သည်။ အသုံးပြုသူအပလီကေးရှင်းများကို ချိတ်ဆက်ခြင်းဖြင့် IOUserClient ထံမှ အမွေဆက်ခံသော အတန်း၏ instance အသစ်ကို ဖန်တီးစေသည်၊ ဥပမာ my_kext_iouserclient တွင်၊

စနစ် (kextunload command) မှ ဒရိုက်ဘာကို ဖြုတ်ချရန် ကြိုးစားသောအခါ၊ virtual function “bool terminate(IOOptionBits options)” ကို ခေါ်သည်။ kextunload ကို disable လုပ်ပြီး unload လုပ်ဖို့ကြိုးစားတဲ့အခါ ခေါ်ဆိုမှုမှာ false ပြန်လာဖို့ လုံလောက်ပါတယ်။

bool Kext::terminate(IOOptionBits options)
{

  if (!IsUnloadAllowed)
  {
    // Unload is not allowed, returning false
    return false;
  }

  return super::terminate(options);
}

တင်သည့်အခါ IsUnloadAllowed အလံကို IOUserClient က သတ်မှတ်နိုင်သည်။ ဒေါင်းလုဒ်ကန့်သတ်ချက်ရှိပါက kextunload command သည် အောက်ပါ output ကို ပြန်ပေးလိမ့်မည်-

admin@admins-Mac drivermanager % sudo kextunload ./test.kext
Password:
(kernel) Can't remove kext my.kext.test; services failed to terminate - 0xe00002c7.
Failed to unload my.kext.test - (iokit/common) unsupported function.

IOUserClient အတွက် အလားတူကာကွယ်မှုပြုလုပ်ရပါမည်။ IOKitLib userspace လုပ်ဆောင်ချက် “IOCatalogueTerminate(mach_port_t၊ uint32_t အလံ၊ io_name_t ဖော်ပြချက်);” ကို အသုံးပြု၍ အတန်းများ၏ ဖြစ်ရပ်များကို ပြန်ဖွင့်နိုင်သည်။ userspace အပလီကေးရှင်း "သေ" ဟူသော အဓိပ္ပါယ်မှာ "clientDied" လုပ်ဆောင်ချက်ကို မခေါ်မချင်း "terminate" အမိန့်ကို ခေါ်ဆိုသောအခါ သင်သည် false ပြန်ပေးနိုင်သည်။

ဖိုင်ကာကွယ်ရေး

ဖိုင်များကိုကာကွယ်ရန်၊ ဖိုင်များဝင်ရောက်ခွင့်ကိုကန့်သတ်ရန်ခွင့်ပြုသော Kauth API ကိုအသုံးပြုရန်လုံလောက်သည်။ Apple သည် နယ်ပယ်အတွင်းရှိ အမျိုးမျိုးသော ဖြစ်ရပ်များအကြောင်း အကြောင်းကြားချက်များကို ဆော့ဖ်ဝဲအင်ဂျင်နီယာများအား ပံ့ပိုးပေးသည်၊ ကျွန်ုပ်တို့အတွက်၊ KAUTH_VNODE_DELETE၊ KAUTH_VNODE_WRITE_DATA နှင့် KAUTH_VNODE_DELETE_CHILD လုပ်ဆောင်ချက်များသည် အရေးကြီးပါသည်။ ဖိုင်များသို့ဝင်ရောက်ခွင့်ကို ကန့်သတ်ရန် အလွယ်ကူဆုံးနည်းလမ်းမှာ လမ်းကြောင်းအားဖြင့်ဖြစ်သည် - ကျွန်ုပ်တို့သည် ဖိုင်သို့လမ်းကြောင်းကိုရယူရန်နှင့် လမ်းကြောင်းရှေ့ဆက်ကို နှိုင်းယှဉ်ရန် "vn_getpath" API ကို အသုံးပြုပါသည်။ ဖိုင်ဖိုင်တွဲလမ်းကြောင်းများကို အမည်ပြောင်းခြင်းအား အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်ရန်၊ စနစ်သည် ဖိုင်တစ်ခုစီသို့ ဝင်ရောက်ခွင့်ကို ခွင့်မပြုသော်လည်း အမည်ပြောင်းထားသည့် ဖိုဒါကိုယ်တိုင်ကိုသာ သတိပြုပါ။ ပင်မလမ်းကြောင်းကို နှိုင်းယှဉ်ပြီး ၎င်းအတွက် KAUTH_VNODE_DELETE ကို ကန့်သတ်ရန် လိုအပ်ပါသည်။

ဤချဉ်းကပ်မှု၏ အားနည်းချက်မှာ ရှေ့ဆက်အရေအတွက် တိုးလာသည်နှင့်အမျှ စွမ်းဆောင်ရည် နိမ့်ပါးနိုင်သည်။ နှိုင်းယှဉ်မှုသည် O(prefix*length) နှင့် မညီမျှကြောင်း သေချာစေရန်အတွက် ရှေ့ဆက်သည် ရှေ့ဆက်အရေအတွက်ဖြစ်ပြီး၊ length သည် string ၏အရှည်ဖြစ်သည်၊ သင်သည် prefix များဖြင့်တည်ဆောက်ထားသော deterministic finite automaton (DFA) ကိုသုံးနိုင်သည်။

ပေးထားသော ရှေ့ဆက်တွဲများအတွက် DFA တစ်ခုကို တည်ဆောက်ရန် နည်းလမ်းကို စဉ်းစားကြည့်ကြပါစို့။ ရှေ့ဆက်တစ်ခုစီ၏အစတွင် ကာဆာများကို ကျွန်ုပ်တို့ စတင်လုပ်ဆောင်ပါသည်။ ကာဆာများအားလုံးသည် တူညီသောအက္ခရာကို ညွှန်ပြပါက၊ ကာဆာတစ်ခုစီကို အက္ခရာတစ်ခုစီဖြင့် တိုးမြှင့်ပြီး တူညီသောစာကြောင်း၏အလျားသည် တစ်ခုပြီးတစ်ခု ပိုကြီးသည်ကို သတိရပါ။ မတူကွဲပြားသော သင်္ကေတများပါသည့် ကာဆာနှစ်ခုရှိပါက၊ ၎င်းတို့ညွှန်ပြသည့် သင်္ကေတအတိုင်း အုပ်စုများခွဲကာ အုပ်စုတစ်ခုစီအတွက် အယ်လဂိုရီသမ်ကို ပြန်လုပ်ပါ။

ပထမကိစ္စတွင် (ကာဆာအောက်ရှိ စာလုံးအားလုံးသည် တူညီသည်)၊ ကျွန်ုပ်တို့သည် တူညီသောမျဉ်းတစ်လျှောက် ကူးပြောင်းမှုတစ်ခုသာရှိသော DFA အခြေအနေတစ်ခုကို ရရှိသည်။ ဒုတိယအခြေအနေတွင်၊ လုပ်ဆောင်ချက်ကို ထပ်ခါတလဲလဲခေါ်ဆိုခြင်းဖြင့် ရရှိသော နောက်ဆက်တွဲအခြေအနေများသို့ စာလုံးအရေအတွက် 256 (စာလုံးအရေအတွက်နှင့် အများဆုံးအုပ်စုအရေအတွက်) ၏ အကူးအပြောင်းဇယားတစ်ခုကို ကျွန်ုပ်တို့ရရှိသည်။

ဥပမာတစ်ခုကိုကြည့်ရအောင်။ ရှေ့ဆက်တွဲများ (“/foo/bar/tmp/”၊ “/var/db/foo/”၊ “/foo/bar/aba/”၊ “foo/bar/aac/”) အောက်ပါတို့ကို သင်ရနိုင်သည် DFA ကိန်းဂဏန်းသည် အခြားပြည်နယ်များသို့ ဦးတည်သော အသွင်ကူးပြောင်းမှုများကိုသာ ပြသသည်၊ အခြားအကူးအပြောင်းများသည် အပြီးသတ်မည်မဟုတ်ပါ။

DKA ပြည်နယ်တွေကို ဖြတ်သွားတဲ့အခါ အမှု ၃ မှု ရှိနိုင်ပါတယ်။

1. နောက်ဆုံးအခြေအနေသို့ ရောက်ရှိသွားပါပြီ - လမ်းကြောင်းကို ကာကွယ်ထားပြီး၊ ကျွန်ုပ်တို့သည် KAUTH_VNODE_DELETE၊ KAUTH_VNODE_WRITE_DATA နှင့် KAUTH_VNODE_DELETE_CHILD လုပ်ဆောင်ချက်များကို ကန့်သတ်ထားပါသည်။
2. နောက်ဆုံးအခြေအနေသို့ မရောက်သေးသော်လည်း "ပြီးဆုံးသည်" လမ်းကြောင်း ( null terminator ကိုရောက်ရှိခဲ့သည်) - လမ်းကြောင်းသည် မိဘဖြစ်သည်၊ KAUTH_VNODE_DELETE ကို ကန့်သတ်ရန် လိုအပ်ပါသည်။ vnode သည် ဖိုဒါတစ်ခုဖြစ်ပါက၊ သင်သည် အဆုံးတွင် '/' ကို ထည့်ရန် လိုအပ်သည်၊ သို့မဟုတ်ပါက ၎င်းသည် မှားယွင်းနေသည့် ဖိုင် “/foor/bar/t” တွင် ကန့်သတ်ထားနိုင်သည်ကို သတိပြုပါ။
3. နောက်ဆုံးအခြေအနေသို့ မရောက်၊ လမ်းကြောင်းမဆုံးပါ။ ရှေ့ဆက်တွဲများ တစ်ခုမှ ဤတစ်ခုနှင့် ကိုက်ညီမှုမရှိပါ၊ ကျွန်ုပ်တို့သည် ကန့်သတ်ချက်များကို မဖော်ပြပါ။

ကောက်ချက်

လုံခြုံရေးဖြေရှင်းနည်းများ တီထွင်ထုတ်လုပ်ခြင်း၏ ရည်ရွယ်ချက်မှာ သုံးစွဲသူနှင့် သူ၏ဒေတာများ၏ လုံခြုံရေးအဆင့်ကို တိုးမြှင့်ရန်ဖြစ်သည်။ တစ်ဖက်တွင်၊ လည်ပတ်မှုစနစ်ကိုယ်တိုင် “အားနည်း” သည့် အဆိုပါအားနည်းချက်များကို ပိတ်ပေးသည့် Acronis ဆော့ဖ်ဝဲထုတ်ကုန်ကို တီထွင်ခြင်းဖြင့် ဤပန်းတိုင်ကို အကောင်အထည်ဖော်နိုင်မည်ဖြစ်သည်။ တစ်ဖက်တွင်၊ အထူးသဖြင့် အဆိုပါအားနည်းချက်များကိုပိတ်ခြင်းဖြင့် ထုတ်ကုန်တစ်ခုအနေဖြင့် ကျွန်ုပ်တို့၏ကိုယ်ပိုင်တည်ငြိမ်မှုကို တိုးမြင့်စေသောကြောင့် OS ဘက်တွင် ပိုမိုကောင်းမွန်လာစေနိုင်သည့် အဆိုပါလုံခြုံရေးကဏ္ဍများကို အားကောင်းလာစေရန်အတွက် ကျွန်ုပ်တို့လျစ်လျူမရှုသင့်ပါ။ အားနည်းချက်ကို Apple ထုတ်ကုန်လုံခြုံရေးအဖွဲ့ထံ တိုင်ကြားထားပြီး macOS 10.14.5 (https://support.apple.com/en-gb/HT210119) တွင် ပြင်ဆင်ပြီးဖြစ်သည်။

သင်၏ utility ကို kernel တွင်တရားဝင်ထည့်သွင်းထားမှသာဤအရာအားလုံးကိုလုပ်ဆောင်နိုင်သည်။ ဆိုလိုသည်မှာ၊ ပြင်ပနှင့် မလိုလားအပ်သော ဆော့ဖ်ဝဲလ်များအတွက် ထိုကဲ့သို့သော ကွက်လပ်များ မရှိပါ။ သို့သော်၊ သင်တွေ့မြင်ရသည့်အတိုင်း၊ ဗိုင်းရပ်စ်နှင့် အရန်စနစ်များကဲ့သို့သော တရားဝင်ပရိုဂရမ်များကို ကာကွယ်ရန်ပင် လုပ်ဆောင်ရန် လိုအပ်ပါသည်။ သို့သော် ယခု macOS အတွက် Acronis ထုတ်ကုန်အသစ်များသည် စနစ်မှ လွှင့်ထုတ်ခြင်းမှ ထပ်လောင်းကာကွယ်မှု ရှိလာမည်ဖြစ်သည်။

source: www.habr.com