ວິທີການປົກປ້ອງຂະບວນການແລະການຂະຫຍາຍແກ່ນໃນ macOS

ສະບາຍດີ, Habr! ມື້ນີ້ຂ້ອຍຢາກເວົ້າກ່ຽວກັບວິທີທີ່ທ່ານສາມາດປົກປ້ອງຂະບວນການຈາກການໂຈມຕີໂດຍຜູ້ໂຈມຕີໃນ macOS. ສໍາລັບຕົວຢ່າງ, ນີ້ແມ່ນເປັນປະໂຫຍດສໍາລັບລະບົບຕ້ານໄວລັດຫຼືສໍາຮອງຂໍ້ມູນ, ໂດຍສະເພາະເນື່ອງຈາກວ່າພາຍໃຕ້ macOS ມີຫຼາຍວິທີທີ່ຈະ "ຂ້າ" ຂະບວນການ. ອ່ານກ່ຽວກັບເລື່ອງນີ້ແລະວິທີການປ້ອງກັນພາຍໃຕ້ການຕັດ.

ວິທີການຄລາສສິກທີ່ຈະ "ຂ້າ" ຂະບວນການ

ວິທີທີ່ຮູ້ຈັກກັນດີທີ່ຈະ "ຂ້າ" ຂະບວນການແມ່ນການສົ່ງສັນຍານ SIGKILL ໄປຫາຂະບວນການ. ໂດຍຜ່ານ bash ທ່ານສາມາດໂທຫາມາດຕະຖານ "ຂ້າ -SIGKILL PID" ຫຼື "pkill -9 NAME" ເພື່ອຂ້າ. ຄໍາສັ່ງ "ຂ້າ" ເປັນທີ່ຮູ້ຈັກຕັ້ງແຕ່ສະ ໄໝ ຂອງ UNIX ແລະບໍ່ພຽງແຕ່ມີຢູ່ໃນ macOS ເທົ່ານັ້ນ, ແຕ່ຍັງຢູ່ໃນລະບົບອື່ນໆທີ່ຄ້າຍຄືກັບ UNIX.

ຄືກັນກັບໃນລະບົບທີ່ຄ້າຍຄືກັບ UNIX, macOS ຊ່ວຍໃຫ້ທ່ານສາມາດຂັດຂວາງສັນຍານໃດໆໃນຂະບວນການຍົກເວັ້ນສອງ - SIGKILL ແລະ SIGSTOP. ບົດຄວາມນີ້ຕົ້ນຕໍຈະເນັ້ນໃສ່ສັນຍານ SIGKILL ເປັນສັນຍານທີ່ເຮັດໃຫ້ຂະບວນການຖືກຂ້າຕາຍ.

ສະເພາະ macOS

ໃນ macOS, ການເອີ້ນລະບົບ kill ໃນ kernel XNU ເອີ້ນຟັງຊັນ psignal(SIGKILL,...). ໃຫ້ລອງເບິ່ງສິ່ງທີ່ປະຕິບັດຂອງຜູ້ໃຊ້ອື່ນໃນພື້ນທີ່ຜູ້ໃຊ້ສາມາດເອີ້ນໄດ້ໂດຍຫນ້າທີ່ psignal. ໃຫ້ພວກເຮົາກໍາຈັດການໂທຫາຫນ້າທີ່ psignal ໃນກົນໄກພາຍໃນຂອງແກ່ນ (ເຖິງແມ່ນວ່າມັນອາດຈະບໍ່ແມ່ນເລື່ອງເລັກນ້ອຍ, ພວກເຮົາຈະປ່ອຍໃຫ້ມັນສໍາລັບບົດຄວາມອື່ນ 🙂 - ການກວດສອບລາຍເຊັນ, ຄວາມຜິດພາດຂອງຫນ່ວຍຄວາມຈໍາ, ການອອກ / ຢຸດການຈັດການ, ການລະເມີດການປົກປ້ອງໄຟລ໌, ແລະອື່ນໆ. .

ໃຫ້ເລີ່ມຕົ້ນການທົບທວນຄືນກັບຫນ້າທີ່ແລະການໂທຫາລະບົບທີ່ສອດຄ້ອງກັນ terminate_with_payload. ມັນສາມາດເຫັນໄດ້ວ່ານອກເຫນືອຈາກການໂທ kill ຄລາສສິກ, ມີວິທີການທາງເລືອກທີ່ສະເພາະກັບລະບົບປະຕິບັດການ macOS ແລະບໍ່ພົບໃນ BSD. ຫຼັກການການດໍາເນີນງານຂອງການໂທລະບົບທັງສອງແມ່ນຄ້າຍຄືກັນ. ພວກເຂົາເຈົ້າແມ່ນການໂທໂດຍກົງກັບຫນ້າທີ່ kernel 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);
	}
...
}

ເປີດຕົວ

ວິທີການມາດຕະຖານໃນການສ້າງ daemon ໃນຕອນເລີ່ມຕົ້ນຂອງລະບົບແລະຄວບຄຸມຊີວິດຂອງພວກເຂົາແມ່ນເປີດຕົວ. ກະລຸນາຮັບຊາບວ່າແຫຼ່ງຂໍ້ມູນແມ່ນສໍາລັບ launchctl ຮຸ່ນເກົ່າເຖິງ macOS 10.10, ຕົວຢ່າງລະຫັດແມ່ນສະຫນອງໃຫ້ເພື່ອຈຸດປະສົງຕົວຢ່າງ. launchctl ທີ່ທັນສະໄຫມສົ່ງສັນຍານເປີດຕົວຜ່ານ XPC, 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));
		} 
...
<>

ພາຍໃຕ້ hood, proc_terminate, ເຖິງວ່າຈະມີຊື່ຂອງມັນ, ສາມາດສົ່ງບໍ່ພຽງແຕ່ psignal ກັບ SIGTERM, ແຕ່ຍັງ SIGKILL.

ການຂ້າທາງອ້ອມ - ຈໍາກັດຊັບພະຍາກອນ

ກໍລະນີທີ່ຫນ້າສົນໃຈຫຼາຍສາມາດເຫັນໄດ້ໃນການໂທລະບົບອື່ນ process_policy. ການນໍາໃຊ້ທົ່ວໄປຂອງການໂທລະບົບນີ້ແມ່ນເພື່ອຈໍາກັດຊັບພະຍາກອນຂອງແອັບພລິເຄຊັນ, ເຊັ່ນ: ສໍາລັບຕົວດັດສະນີເພື່ອຈໍາກັດເວລາ CPU ແລະໂຄຕ້າຫນ່ວຍຄວາມຈໍາເພື່ອບໍ່ໃຫ້ລະບົບຊ້າລົງຢ່າງຫຼວງຫຼາຍໂດຍກິດຈະກໍາການເກັບໄຟລ໌. ຖ້າແອັບພລິເຄຊັນໄດ້ເຖິງຂີດຈຳກັດຊັບພະຍາກອນຂອງມັນ, ດັ່ງທີ່ເຫັນໄດ້ຈາກຟັງຊັນ proc_apply_resource_actions, ສັນຍານ SIGKILL ຈະຖືກສົ່ງໄປຫາຂະບວນການ.

ເຖິງແມ່ນວ່າການໂທລະບົບນີ້ສາມາດຂ້າຂະບວນການໃດຫນຶ່ງ, ແຕ່ລະບົບບໍ່ໄດ້ກວດສອບສິດທິຂອງຂະບວນການໂທຫາລະບົບຢ່າງພຽງພໍ. ກວດສອບຕົວຈິງ ມີຢູ່, ແຕ່ມັນພຽງພໍທີ່ຈະໃຊ້ທຸງທາງເລືອກ PROC_POLICY_ACTION_SET ເພື່ອຂ້າມເງື່ອນໄຂນີ້.

ດັ່ງນັ້ນ, ຖ້າທ່ານ "ຈໍາກັດ" ໂຄຕ້າການນໍາໃຊ້ CPU ຂອງແອັບພລິເຄຊັນ (ຕົວຢ່າງ, ອະນຸຍາດໃຫ້ພຽງແຕ່ 1 ns ດໍາເນີນການ), ຫຼັງຈາກນັ້ນທ່ານສາມາດຂ້າຂະບວນການໃດໆໃນລະບົບ. ດັ່ງນັ້ນ, malware ສາມາດຂ້າຂະບວນການໃດໆໃນລະບົບ, ລວມທັງຂະບວນການ antivirus. ຍັງຫນ້າສົນໃຈແມ່ນຜົນກະທົບທີ່ເກີດຂື້ນໃນເວລາທີ່ຂ້າຂະບວນການທີ່ມີ pid 1 (launchctl) - kernel panic ໃນເວລາທີ່ພະຍາຍາມປະມວນຜົນສັນຍານ SIGKILL :)

ວິທີການແກ້ໄຂບັນຫາ?

ວິທີທີ່ກົງໄປກົງມາທີ່ສຸດເພື່ອປ້ອງກັນບໍ່ໃຫ້ຂະບວນການຖືກຂ້າແມ່ນການທົດແທນຕົວຊີ້ຫນ້າທີ່ຢູ່ໃນຕາຕະລາງການໂທລະບົບ. ແຕ່ຫນ້າເສຍດາຍ, ວິທີການນີ້ແມ່ນບໍ່ສໍາຄັນສໍາລັບຫຼາຍເຫດຜົນ.

ທໍາອິດ, ສັນຍາລັກທີ່ຄວບຄຸມສະຖານທີ່ຫນ່ວຍຄວາມຈໍາຂອງ sysent ບໍ່ພຽງແຕ່ເປັນສ່ວນຕົວຂອງສັນຍາລັກແກ່ນ XNU, ແຕ່ບໍ່ສາມາດພົບເຫັນຢູ່ໃນສັນຍາລັກຂອງແກ່ນ. ທ່ານຈະຕ້ອງໃຊ້ວິທີການຄົ້ນຫາແບບ heuristic, ເຊັ່ນ: ການຖອດການເຮັດວຽກແບບເຄື່ອນໄຫວແລະການຊອກຫາຕົວຊີ້ໃນມັນ.

ອັນທີສອງ, ໂຄງສ້າງຂອງລາຍການໃນຕາຕະລາງແມ່ນຂຶ້ນກັບທຸງທີ່ kernel ໄດ້ຖືກລວບລວມ. ຖ້າທຸງ CONFIG_REQUIRES_U32_MUNGING ຖືກປະກາດ, ຂະໜາດຂອງໂຄງສ້າງຈະຖືກປ່ຽນ - ຊ່ອງຂໍ້ມູນເພີ່ມເຕີມຈະຖືກເພີ່ມ. sy_arg_munge32. ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະດໍາເນີນການກວດສອບເພີ່ມເຕີມເພື່ອກໍານົດວ່າທຸງໃດທີ່ຖືກລວບລວມດ້ວຍ, ຫຼືອີກທາງເລືອກຫນຶ່ງ, ກວດເບິ່ງຕົວຊີ້ຟັງຊັນຕໍ່ກັບສິ່ງທີ່ຮູ້ຈັກ.

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 ອະນຸຍາດໃຫ້ລູກຄ້າອະນຸຍາດຫຼາຍຄໍາຮ້ອງຂໍໃຫ້ກັບຂະບວນການອື່ນໆ. ດັ່ງນັ້ນ, ທ່ານສາມາດສະກັດສັນຍານໃດໆທີ່ຈະດໍາເນີນການ, ລວມທັງສັນຍານ SIGKILL, ໂດຍໃຊ້ API ທີ່ກ່າວມາຂ້າງເທິງ.

#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;
}

ເຊັ່ນດຽວກັນ, ນະໂຍບາຍ MAC ສາມາດລົງທະບຽນຢູ່ໃນ kernel, ເຊິ່ງສະຫນອງວິທີການປ້ອງກັນສັນຍານ (ນະໂຍບາຍ proc_check_signal), ແຕ່ API ບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນຢ່າງເປັນທາງການ.

ການປົກປ້ອງສ່ວນຂະຫຍາຍ Kernel

ນອກເຫນືອຈາກການປົກປ້ອງຂະບວນການໃນລະບົບ, ການປົກປ້ອງສ່ວນຂະຫຍາຍແກ່ນຂອງມັນເອງ (kext) ຍັງມີຄວາມຈໍາເປັນ. macOS ສະຫນອງກອບສໍາລັບນັກພັດທະນາເພື່ອພັດທະນາໄດເວີອຸປະກອນ IOKit ໄດ້ຢ່າງງ່າຍດາຍ. ນອກເຫນືອຈາກການສະຫນອງເຄື່ອງມືສໍາລັບການເຮັດວຽກກັບອຸປະກອນ, IOKit ສະຫນອງວິທີການສໍາລັບການ stacking driver ໂດຍໃຊ້ຕົວຢ່າງຂອງຫ້ອງຮຽນ C ++. ແອັບພລິເຄຊັນທີ່ຢູ່ໃນພື້ນທີ່ຜູ້ໃຊ້ຈະສາມາດ "ຊອກຫາ" ຕົວຢ່າງທີ່ລົງທະບຽນຂອງຊັ້ນຮຽນເພື່ອສ້າງຄວາມສໍາພັນກັບ kernel-userspace.

ເພື່ອກວດຫາຈຳນວນຂອງ class instances ໃນລະບົບ, ມີ ioclasscount utility.

my_kext_ioservice = 1
my_kext_iouserclient = 1

ສ່ວນຂະຫຍາຍ kernel ທີ່ຕ້ອງການລົງທະບຽນກັບ driver stack ຕ້ອງປະກາດ class ທີ່ສືບທອດມາຈາກ IOService, ຕົວຢ່າງ my_kext_ioservice ໃນກໍລະນີນີ້. ການເຊື່ອມຕໍ່ແອັບພລິເຄຊັນຂອງຜູ້ໃຊ້ເຮັດໃຫ້ການສ້າງ instance ໃໝ່ຂອງ class ທີ່ສືບທອດມາຈາກ IOUserClient, ໃນຕົວຢ່າງ my_kext_iouserclient.

ເມື່ອພະຍາຍາມຍົກເລີກການໂຫຼດໄດເວີຈາກລະບົບ (ຄໍາສັ່ງ kextunload), ຟັງຊັນ virtual "bool terminate (IOOptionBits options)" ຖືກເອີ້ນວ່າ. ມັນພຽງພໍທີ່ຈະກັບຄືນ false ໃນການໂທເພື່ອຢຸດໃນເວລາທີ່ພະຍາຍາມ unload ເພື່ອປິດການໃຊ້ງານ kextunload.

bool Kext::terminate(IOOptionBits options)
{

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

  return super::terminate(options);
}

ທຸງ IsUnloadAllowed ສາມາດຖືກກໍານົດໂດຍ IOUserClient ເມື່ອໂຫລດ. ເມື່ອມີການຈຳກັດການດາວໂຫຼດ, ຄຳສັ່ງ kextunload ຈະສົ່ງຄືນຜົນຜະລິດຕໍ່ໄປນີ້:

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 “IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t description);”. ທ່ານສາມາດສົ່ງຄືນຂໍ້ມູນທີ່ບໍ່ຖືກຕ້ອງໃນເວລາທີ່ໂທຫາຄໍາສັ່ງ "ສິ້ນສຸດ" ຈົນກ່ວາຄໍາຮ້ອງສະຫມັກພື້ນທີ່ຜູ້ໃຊ້ "ຕາຍ", ນັ້ນແມ່ນ, ຟັງຊັນ "clientDied" ບໍ່ໄດ້ຖືກເອີ້ນ.

ການປົກປ້ອງໄຟລ໌

ເພື່ອປົກປ້ອງໄຟລ໌, ມັນພຽງພໍທີ່ຈະໃຊ້ Kauth API, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດຈໍາກັດການເຂົ້າເຖິງໄຟລ໌. Apple ໃຫ້ນັກພັດທະນາມີການແຈ້ງເຕືອນກ່ຽວກັບເຫດການຕ່າງໆໃນຂອບເຂດ; ສໍາລັບພວກເຮົາ, ການດໍາເນີນງານ KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA ແລະ KAUTH_VNODE_DELETE_CHILD ແມ່ນສໍາຄັນ. ວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະຈໍາກັດການເຂົ້າເຖິງໄຟລ໌ແມ່ນໄປຕາມເສັ້ນທາງ - ພວກເຮົາໃຊ້ API "vn_getpath" ເພື່ອເອົາເສັ້ນທາງໄປຫາໄຟລ໌ແລະປຽບທຽບຄໍານໍາຫນ້າເສັ້ນທາງ. ໃຫ້ສັງເກດວ່າເພື່ອເພີ່ມປະສິດທິພາບການປ່ຽນຊື່ຂອງເສັ້ນທາງໂຟເດີໄຟລ໌, ລະບົບບໍ່ໄດ້ອະນຸຍາດໃຫ້ເຂົ້າເຖິງແຕ່ລະໄຟລ໌, ແຕ່ວ່າພຽງແຕ່ກັບໂຟເດີຕົວມັນເອງທີ່ຖືກປ່ຽນຊື່. ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະປຽບທຽບເສັ້ນທາງຂອງພໍ່ແມ່ແລະຈໍາກັດ KAUTH_VNODE_DELETE ສໍາລັບມັນ.

ຂໍ້ເສຍຂອງວິທີການນີ້ອາດຈະເປັນການປະຕິບັດຕ່ໍາຍ້ອນວ່າຈໍານວນຄໍານໍາຫນ້າເພີ່ມຂຶ້ນ. ເພື່ອໃຫ້ແນ່ໃຈວ່າການປຽບທຽບບໍ່ເທົ່າກັບ O (prefix*length), ເຊິ່ງຄໍານໍາຫນ້າແມ່ນຈໍານວນຄໍານໍາຫນ້າ, ຄວາມຍາວແມ່ນຄວາມຍາວຂອງສາຍ, ທ່ານສາມາດນໍາໃຊ້ automaton finite finite (DFA) ທີ່ສ້າງຂຶ້ນໂດຍຄໍານໍາຫນ້າ.

ໃຫ້ພິຈາລະນາວິທີການສ້າງ DFA ສໍາລັບຊຸດຂອງຄໍານໍາຫນ້າ. ພວກເຮົາເລີ່ມຕົ້ນຕົວກະພິບໃນຕອນຕົ້ນຂອງແຕ່ລະຄໍານໍາຫນ້າ. ຖ້າຕົວກະພິບທັງຫມົດຊີ້ໃຫ້ເຫັນເຖິງຕົວອັກສອນດຽວກັນ, ຫຼັງຈາກນັ້ນໃຫ້ແຕ່ລະຕົວກະພິບເພີ່ມຂຶ້ນຫນຶ່ງຕົວອັກສອນແລະຈື່ໄວ້ວ່າຄວາມຍາວຂອງເສັ້ນດຽວກັນແມ່ນໃຫຍ່ກວ່າຫນຶ່ງຕົວ. ຖ້າມີສອງຕົວກະພິບທີ່ມີສັນຍາລັກທີ່ແຕກຕ່າງກັນ, ແບ່ງຕົວກະພິບອອກເປັນກຸ່ມຕາມສັນຍາລັກທີ່ພວກເຂົາຊີ້ໄປຫາແລະເຮັດຊ້ໍາຂັ້ນຕອນຂອງແຕ່ລະກຸ່ມ.

ໃນກໍລະນີທໍາອິດ (ຕົວອັກສອນທັງຫມົດພາຍໃຕ້ຕົວກະພິບແມ່ນຄືກັນ), ພວກເຮົາໄດ້ຮັບສະຖານະ DFA ທີ່ມີພຽງແຕ່ຫນຶ່ງການປ່ຽນແປງຕາມເສັ້ນດຽວກັນ. ໃນກໍລະນີທີສອງ, ພວກເຮົາໄດ້ຮັບຕາຕະລາງການປ່ຽນແປງຂອງຂະຫນາດ 256 (ຈໍານວນຕົວອັກສອນແລະຈໍານວນສູງສຸດຂອງກຸ່ມ) ໄປຫາລັດຕໍ່ມາທີ່ໄດ້ຮັບໂດຍການເອີ້ນຄືນຟັງຊັນ.

ໃຫ້ເບິ່ງຕົວຢ່າງ. ສໍາລັບຊຸດຂອງຄໍານໍາຫນ້າ (“/foo/bar/tmp/”, “/var/db/foo/”, “/foo/bar/aba/”, “foo/bar/aac/”) ທ່ານສາມາດໄດ້ຮັບຕໍ່ໄປນີ້. DFA. ຕົວ​ເລກ​ສະ​ແດງ​ໃຫ້​ເຫັນ​ພຽງ​ແຕ່​ການ​ຫັນ​ປ່ຽນ​ທີ່​ນຳ​ໄປ​ສູ່​ລັດ​ອື່ນໆ; ການ​ຫັນ​ປ່ຽນ​ອື່ນໆ​ຈະ​ບໍ່​ແມ່ນ​ການ​ສິ້ນ​ສຸດ​ລົງ.

ເມື່ອຜ່ານລັດ DKA, ອາດຈະມີ 3 ກໍລະນີ.

1. ມາຮອດສະຖານະສຸດທ້າຍແລ້ວ - ເສັ້ນທາງຖືກປົກປ້ອງ, ພວກເຮົາຈຳກັດການດຳເນີນການ KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA ແລະ KAUTH_VNODE_DELETE_CHILD
2. ສະຖານະສຸດທ້າຍບໍ່ໄດ້ບັນລຸ, ແຕ່ເສັ້ນທາງ "ສິ້ນສຸດລົງ" (ໄດ້ເຖິງຈຸດສິ້ນສຸດ null) - ເສັ້ນທາງແມ່ນພໍ່ແມ່, ມັນຈໍາເປັນຕ້ອງຈໍາກັດ KAUTH_VNODE_DELETE. ໃຫ້ສັງເກດວ່າຖ້າ vnode ເປັນໂຟນເດີ, ທ່ານຈໍາເປັນຕ້ອງເພີ່ມ '/' ໃນຕອນທ້າຍ, ຖ້າບໍ່ດັ່ງນັ້ນມັນອາດຈະຈໍາກັດມັນຢູ່ໃນໄຟລ໌ "/foor/bar/t", ເຊິ່ງບໍ່ຖືກຕ້ອງ.
3. ລັດສຸດທ້າຍບໍ່ໄດ້ບັນລຸ, ເສັ້ນທາງບໍ່ໄດ້ສິ້ນສຸດ. ບໍ່ມີຄຳນຳໜ້າອັນໃດກົງກັບອັນນີ້, ພວກເຮົາບໍ່ໄດ້ແນະນຳຂໍ້ຈຳກັດ.

ສະຫລຸບ

ເປົ້າຫມາຍຂອງການແກ້ໄຂຄວາມປອດໄພທີ່ກໍາລັງພັດທະນາແມ່ນເພື່ອເພີ່ມລະດັບຄວາມປອດໄພຂອງຜູ້ໃຊ້ແລະຂໍ້ມູນຂອງລາວ. ໃນອີກດ້ານຫນຶ່ງ, ເປົ້າຫມາຍນີ້ແມ່ນບັນລຸໄດ້ໂດຍການພັດທະນາຜະລິດຕະພັນຊໍແວ Acronis, ເຊິ່ງປິດຊ່ອງໂຫວ່ເຫຼົ່ານັ້ນທີ່ລະບົບປະຕິບັດງານຂອງມັນເອງ "ອ່ອນແອ". ໃນທາງກົງກັນຂ້າມ, ພວກເຮົາບໍ່ຄວນລະເລີຍການສ້າງຄວາມເຂັ້ມແຂງດ້ານຄວາມປອດໄພເຫຼົ່ານັ້ນທີ່ສາມາດປັບປຸງໄດ້ໃນດ້ານ OS, ໂດຍສະເພາະນັບຕັ້ງແຕ່ການປິດຊ່ອງໂຫວ່ດັ່ງກ່າວເພີ່ມຄວາມຫມັ້ນຄົງຂອງພວກເຮົາເປັນຜະລິດຕະພັນ. ຊ່ອງໂຫວ່ໄດ້ຖືກລາຍງານໃຫ້ທີມງານຄວາມປອດໄພຜະລິດຕະພັນ Apple ແລະໄດ້ຮັບການແກ້ໄຂໃນ macOS 10.14.5 (https://support.apple.com/en-gb/HT210119).

ທັງຫມົດນີ້ສາມາດເຮັດໄດ້ພຽງແຕ່ຖ້າຫາກວ່າຜົນປະໂຫຍດຂອງທ່ານໄດ້ຖືກຕິດຕັ້ງຢ່າງເປັນທາງການເຂົ້າໄປໃນ kernel. ນັ້ນແມ່ນ, ບໍ່ມີຊ່ອງຫວ່າງດັ່ງກ່າວສໍາລັບຊອບແວພາຍນອກແລະທີ່ບໍ່ຕ້ອງການ. ຢ່າງໃດກໍຕາມ, ຕາມທີ່ທ່ານສາມາດເບິ່ງເຫັນໄດ້, ເຖິງແມ່ນວ່າການປົກປ້ອງໂຄງການທີ່ຖືກຕ້ອງຕາມກົດຫມາຍເຊັ່ນ: antivirus ແລະລະບົບສໍາຮອງຂໍ້ມູນຮຽກຮ້ອງໃຫ້ມີການເຮັດວຽກ. ແຕ່ດຽວນີ້ຜະລິດຕະພັນ Acronis ໃໝ່ ສຳ ລັບ macOS ຈະມີການປ້ອງກັນເພີ່ມເຕີມຕໍ່ການຖອນອອກຈາກລະບົບ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com