របៀបការពារដំណើរការ និងផ្នែកបន្ថែមខឺណែលនៅលើ macOS

សួស្តី ហាប! ថ្ងៃនេះខ្ញុំចង់និយាយអំពីរបៀបដែលអ្នកអាចការពារដំណើរការពីការវាយប្រហារដោយអ្នកវាយប្រហារនៅក្នុង macOS ។ ឧទាហរណ៍ វាមានប្រយោជន៍សម្រាប់ប្រព័ន្ធកំចាត់មេរោគ ឬប្រព័ន្ធបម្រុងទុក ជាពិសេសចាប់តាំងពីនៅក្រោម macOS មានវិធីជាច្រើនដើម្បី "សម្លាប់" ដំណើរការមួយ។ អានអំពីបញ្ហានេះនិងវិធីសាស្រ្តការពារនៅក្រោមការកាត់។

វិធីបុរាណដើម្បី "សម្លាប់" ដំណើរការមួយ។

មធ្យោបាយដ៏ល្បីមួយដើម្បី "សម្លាប់" ដំណើរការគឺការបញ្ជូនសញ្ញា SIGKILL ទៅកាន់ដំណើរការ។ តាមរយៈ bash អ្នកអាចហៅស្តង់ដារ "សម្លាប់ -SIGKILL PID" ឬ "pkill -9 NAME" ដើម្បីសម្លាប់។ ពាក្យបញ្ជា "សម្លាប់" ត្រូវបានគេស្គាល់តាំងពីសម័យយូនីក ហើយមានមិនត្រឹមតែនៅលើ macOS ប៉ុណ្ណោះទេ ប៉ុន្តែក៏មាននៅលើប្រព័ន្ធស្រដៀងនឹងយូនីកផ្សេងទៀតផងដែរ។

ដូចនៅក្នុងប្រព័ន្ធដូច UNIX ដែរ macOS អនុញ្ញាតឱ្យអ្នកស្ទាក់ចាប់សញ្ញាណាមួយទៅកាន់ដំណើរការមួយ លើកលែងតែពីរ - SIGKILL និង SIGSTOP ។ អត្ថបទនេះនឹងផ្តោតជាចម្បងលើសញ្ញា SIGKILL ជាសញ្ញាដែលបណ្តាលឱ្យដំណើរការមួយត្រូវបានសម្លាប់។

លក្ខណៈពិសេស macOS

នៅលើ macOS ការហៅប្រព័ន្ធសម្លាប់នៅក្នុងខឺណែល XNU ហៅមុខងារ psignal(SIGKILL,...)។ តោះព្យាយាមមើលថាតើសកម្មភាពរបស់អ្នកប្រើផ្សេងទៀតនៅក្នុង userspace អាចត្រូវបានហៅដោយមុខងារ psignal ។ ចូរលុបការហៅទៅកាន់មុខងារ psignal នៅក្នុងយន្តការខាងក្នុងនៃខឺណែល (ទោះបីជាវាអាចមិនមែនជារឿងតូចតាចក៏ដោយ យើងនឹងទុកវាសម្រាប់អត្ថបទមួយទៀត🙂 .

ចូរចាប់ផ្តើមការពិនិត្យឡើងវិញជាមួយនឹងមុខងារ និងការហៅប្រព័ន្ធដែលត្រូវគ្នា។ terminate_with_payload. វាអាចត្រូវបានគេមើលឃើញថាបន្ថែមពីលើការហៅសម្លាប់បុរាណមានវិធីសាស្រ្តជំនួសដែលជាក់លាក់ចំពោះប្រព័ន្ធប្រតិបត្តិការ macOS និងមិនត្រូវបានរកឃើញនៅក្នុង BSD ។ គោលការណ៍ប្រតិបត្តិការនៃការហៅប្រព័ន្ធទាំងពីរក៏ស្រដៀងគ្នាដែរ។ ពួកគេគឺជាការហៅដោយផ្ទាល់ទៅកាន់មុខងារខឺណែល 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);
	}
...
}

បានបើកដំណើរការ

វិធីស្តង់ដារដើម្បីបង្កើតដេមិននៅពេលចាប់ផ្តើមប្រព័ន្ធ និងគ្រប់គ្រងអាយុកាលរបស់ពួកគេត្រូវបានបើកដំណើរការ។ សូមចំណាំថាប្រភពគឺសម្រាប់កំណែចាស់របស់ 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));
		} 
...
<>

នៅក្រោមក្រណាត់នោះ proc_terminate ទោះបីជាឈ្មោះរបស់វាក៏ដោយ អាចផ្ញើមិនត្រឹមតែ psignal ជាមួយ SIGTERM ប៉ុណ្ណោះទេប៉ុន្តែថែមទាំង SIGKILL ផងដែរ។

ការសម្លាប់ដោយប្រយោល - ដែនកំណត់ធនធាន

ករណីគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតអាចត្រូវបានគេមើលឃើញនៅក្នុងការហៅតាមប្រព័ន្ធផ្សេងទៀត។ process_policy. ការប្រើប្រាស់ទូទៅនៃការហៅតាមប្រព័ន្ធនេះគឺដើម្បីកំណត់ធនធានកម្មវិធី ដូចជាសម្រាប់អ្នកបង្កើតលិបិក្រមដើម្បីកំណត់ពេលវេលាស៊ីភីយូ និងកូតាសតិ ដូច្នេះប្រព័ន្ធមិនត្រូវបានធ្វើឱ្យយឺតយ៉ាវខ្លាំងដោយសកម្មភាពផ្ទុកឯកសារ។ ប្រសិនបើកម្មវិធីបានឈានដល់ដែនកំណត់ធនធានរបស់វា ដូចដែលអាចមើលឃើញពីមុខងារ proc_apply_resource_actions សញ្ញា SIGKILL ត្រូវបានបញ្ជូនទៅដំណើរការ។

ទោះបីជាការហៅតាមប្រព័ន្ធនេះអាចសម្លាប់ដំណើរការក៏ដោយ ក៏ប្រព័ន្ធមិនបានពិនិត្យឱ្យបានគ្រប់គ្រាន់នូវសិទ្ធិនៃដំណើរការហៅទូរស័ព្ទទៅប្រព័ន្ធនោះទេ។ ពិនិត្យជាក់ស្តែង មានប៉ុន្តែវាគ្រប់គ្រាន់ក្នុងការប្រើទង់ជំនួស PROC_POLICY_ACTION_SET ដើម្បីរំលងលក្ខខណ្ឌនេះ។

ដូច្នេះហើយ ប្រសិនបើអ្នក "កំណត់" កូតានៃការប្រើប្រាស់ CPU របស់កម្មវិធី (ឧទាហរណ៍ អនុញ្ញាតឱ្យដំណើរការត្រឹមតែ 1 ns) នោះអ្នកអាចសម្លាប់ដំណើរការណាមួយនៅក្នុងប្រព័ន្ធបាន។ ដូច្នេះ មេរោគអាចសម្លាប់ដំណើរការណាមួយនៅលើប្រព័ន្ធ រួមទាំងដំណើរការកំចាត់មេរោគផងដែរ។ គួរឱ្យចាប់អារម្មណ៍ផងដែរគឺឥទ្ធិពលដែលកើតឡើងនៅពេលសម្លាប់ដំណើរការជាមួយ pid 1 (launchctl) - ខឺណែលភ័យស្លន់ស្លោនៅពេលព្យាយាមដំណើរការសញ្ញា SIGKILL :)

តើត្រូវដោះស្រាយបញ្ហាដោយរបៀបណា?

មធ្យោបាយត្រង់បំផុតក្នុងការទប់ស្កាត់ដំណើរការមួយពីការសម្លាប់គឺដើម្បីជំនួសទ្រនិចមុខងារនៅក្នុងតារាងហៅប្រព័ន្ធ។ ជាអកុសល វិធីសាស្រ្តនេះគឺមិនសំខាន់សម្រាប់ហេតុផលជាច្រើន។

ទីមួយ និមិត្តសញ្ញាដែលគ្រប់គ្រងទីតាំងអង្គចងចាំរបស់ sysent គឺមិនត្រឹមតែឯកជនចំពោះនិមិត្តសញ្ញាខឺណែល XNU ប៉ុណ្ណោះទេ ប៉ុន្តែមិនអាចរកឃើញនៅក្នុងនិមិត្តសញ្ញាខឺណែលនោះទេ។ អ្នកនឹងត្រូវប្រើវិធីសាស្រ្តស្វែងរកតាមបែបធម្មនុញ្ញ ដូចជាការផ្តាច់មុខងារដោយថាមវន្ត និងស្វែងរកទ្រនិចនៅក្នុងវា។

ទីពីរ រចនាសម្ព័ន្ធនៃធាតុនៅក្នុងតារាងអាស្រ័យលើទង់ដែលខឺណែលត្រូវបានចងក្រង។ ប្រសិនបើទង់ 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 អាចត្រូវបានចុះឈ្មោះនៅក្នុងខឺណែល ដែលផ្តល់វិធីសាស្ត្រការពារសញ្ញា (គោលការណ៍ proc_check_signal) ប៉ុន្តែ API មិនត្រូវបានគាំទ្រជាផ្លូវការទេ។

ការការពារផ្នែកបន្ថែមខឺណែល។

បន្ថែមពីលើការការពារដំណើរការនៅក្នុងប្រព័ន្ធ ការការពារផ្នែកបន្ថែមខឺណែលខ្លួនវា (kext) ក៏ចាំបាច់ផងដែរ។ macOS ផ្តល់​នូវ​ក្របខណ្ឌ​មួយ​សម្រាប់​អ្នក​អភិវឌ្ឍន៍​ដើម្បី​ងាយស្រួល​បង្កើត​កម្មវិធី​បញ្ជា​ឧបករណ៍ IOKit។ បន្ថែមពីលើការផ្តល់ឧបករណ៍សម្រាប់ធ្វើការជាមួយឧបករណ៍ IOKit ផ្តល់នូវវិធីសាស្រ្តសម្រាប់ការជង់កម្មវិធីបញ្ជាដោយប្រើឧទាហរណ៍នៃថ្នាក់ C ++ ។ កម្មវិធីមួយនៅក្នុង userspace នឹងអាច "ស្វែងរក" instance ដែលបានចុះឈ្មោះនៃ class ដើម្បីបង្កើតទំនាក់ទំនង kernel-userspace។

ដើម្បី​រក​ឃើញ​ចំនួន class instances ក្នុង​ប្រព័ន្ធ មាន​ឧបករណ៍​ប្រើប្រាស់ ioclasscount ។

my_kext_ioservice = 1
my_kext_iouserclient = 1

ផ្នែកបន្ថែមខឺណែលណាមួយដែលចង់ចុះឈ្មោះជាមួយជង់កម្មវិធីបញ្ជាត្រូវតែប្រកាសថ្នាក់ដែលទទួលមរតកពី IOService ឧទាហរណ៍ my_kext_ioservice ក្នុងករណីនេះ។ ការភ្ជាប់កម្មវិធីអ្នកប្រើប្រាស់បណ្តាលឱ្យមានការបង្កើត instance ថ្មីនៃ class ដែលទទួលមរតកពី IOUserClient ក្នុងឧទាហរណ៍ my_kext_iouserclient ។

នៅពេលព្យាយាមដកកម្មវិធីបញ្ជាចេញពីប្រព័ន្ធ (ពាក្យបញ្ជា kextunload) មុខងារនិម្មិត "bool terminate(IOOptionBits options)" ត្រូវបានហៅ។ វាគ្រប់គ្រាន់ហើយក្នុងការត្រឡប់មិនពិតនៅលើការហៅទូរស័ព្ទដើម្បីបញ្ចប់នៅពេលព្យាយាម 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 userspace “IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t description);” ។ អ្នកអាចត្រឡប់មិនពិតនៅពេលហៅពាក្យបញ្ជា "បញ្ចប់" រហូតដល់កម្មវិធី userspace "ស្លាប់" នោះគឺមុខងារ "clientDied" មិនត្រូវបានហៅទេ។

ការការពារឯកសារ

ដើម្បីការពារឯកសារ វាគ្រប់គ្រាន់ក្នុងការប្រើ Kauth API ដែលអនុញ្ញាតឱ្យអ្នកដាក់កម្រិតការចូលប្រើឯកសារ។ Apple ផ្តល់ឱ្យអ្នកអភិវឌ្ឍន៍នូវការជូនដំណឹងអំពីព្រឹត្តិការណ៍ផ្សេងៗនៅក្នុងវិសាលភាព សម្រាប់ពួកយើង ប្រតិបត្តិការ KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA និង KAUTH_VNODE_DELETE_CHILD មានសារៈសំខាន់។ មធ្យោបាយងាយស្រួលបំផុតក្នុងការរឹតបន្តឹងការចូលប្រើឯកសារគឺតាមផ្លូវ - យើងប្រើ “vn_getpath” API ដើម្បីទទួលបានផ្លូវទៅកាន់ឯកសារ និងប្រៀបធៀបបុព្វបទផ្លូវ។ សូមចំណាំថា ដើម្បីបង្កើនប្រសិទ្ធភាពការប្តូរឈ្មោះផ្លូវថតឯកសារ ប្រព័ន្ធមិនអនុញ្ញាតឱ្យចូលប្រើឯកសារនីមួយៗទេ ប៉ុន្តែមានតែចំពោះថតឯកសារខ្លួនវាដែលត្រូវបានប្តូរឈ្មោះប៉ុណ្ណោះ។ វាចាំបាច់ដើម្បីប្រៀបធៀបផ្លូវមេ ហើយដាក់កម្រិត KAUTH_VNODE_DELETE សម្រាប់វា។

គុណវិបត្តិនៃវិធីសាស្រ្តនេះអាចនឹងមានដំណើរការទាប ដោយសារចំនួនបុព្វបទកើនឡើង។ ដើម្បីធានាថាការប្រៀបធៀបមិនស្មើនឹង O (បុព្វបទ*ប្រវែង) ដែលបុព្វបទគឺជាចំនួនបុព្វបទ ប្រវែងគឺជាប្រវែងនៃខ្សែ អ្នកអាចប្រើ automaton finite deterministic (DFA) ដែលបង្កើតដោយបុព្វបទ។

ចូរយើងពិចារណាវិធីសាស្រ្តសម្រាប់បង្កើត DFA សម្រាប់សំណុំបុព្វបទដែលបានផ្តល់ឱ្យ។ យើងចាប់ផ្តើមទស្សន៍ទ្រនិចនៅដើមនៃបុព្វបទនីមួយៗ។ ប្រសិនបើទស្សន៍ទ្រនិចទាំងអស់ចង្អុលទៅតួអក្សរដូចគ្នា បន្ទាប់មកបង្កើនទស្សន៍ទ្រនិចនីមួយៗដោយតួអក្សរមួយ ហើយចងចាំថាប្រវែងនៃបន្ទាត់ដូចគ្នាគឺធំជាងមួយ។ ប្រសិនបើមានទស្សន៍ទ្រនិចពីរដែលមាននិមិត្តសញ្ញាផ្សេងគ្នា សូមបែងចែកទស្សន៍ទ្រនិចទៅជាក្រុមតាមនិមិត្តសញ្ញាដែលពួកគេចង្អុលទៅ ហើយធ្វើម្តងទៀតនូវក្បួនដោះស្រាយសម្រាប់ក្រុមនីមួយៗ។

ក្នុងករណីដំបូង (តួអក្សរទាំងអស់នៅក្រោមទស្សន៍ទ្រនិចគឺដូចគ្នា) យើងទទួលបានរដ្ឋ DFA ដែលមានការផ្លាស់ប្តូរតែមួយនៅតាមបណ្តោយបន្ទាត់ដូចគ្នា។ ក្នុងករណីទីពីរ យើងទទួលបានតារាងនៃការផ្លាស់ប្តូរទំហំ 256 (ចំនួនតួអក្សរ និងចំនួនអតិបរមានៃក្រុម) ទៅរដ្ឋជាបន្តបន្ទាប់ដែលទទួលបានដោយការហៅឡើងវិញនូវមុខងារ។

សូមក្រឡេកមើលឧទាហរណ៍មួយ។ សម្រាប់សំណុំនៃបុព្វបទ (“/foo/bar/tmp/”, “/var/db/foo/”, “/foo/bar/aba/”, “foo/bar/aac/”) អ្នកអាចទទួលបានដូចខាងក្រោម ឌីអេហ្វអេ។ តួលេខនេះបង្ហាញតែការផ្លាស់ប្តូរដែលនាំទៅដល់រដ្ឋផ្សេងទៀត ការផ្លាស់ប្តូរផ្សេងទៀតនឹងមិនត្រូវបានបញ្ចប់នោះទេ។

នៅពេលឆ្លងកាត់រដ្ឋ DKA អាចមាន 3 ករណី។

1. ស្ថានភាពចុងក្រោយត្រូវបានឈានដល់ - ផ្លូវត្រូវបានការពារ យើងកំណត់ប្រតិបត្តិការ KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA និង KAUTH_VNODE_DELETE_CHILD
2. ស្ថានភាពចុងក្រោយមិនត្រូវបានឈានដល់ទេ ប៉ុន្តែផ្លូវ "បានបញ្ចប់" (ការបញ្ចប់ជាមោឃៈត្រូវបានឈានដល់) - ផ្លូវគឺជាមេ វាចាំបាច់ក្នុងការកំណត់ KAUTH_VNODE_DELETE ។ ចំណាំថាប្រសិនបើ vnode គឺជាថតមួយ អ្នកត្រូវបន្ថែម '/' នៅចុងបញ្ចប់ បើមិនដូច្នេះទេវាអាចកំណត់វាទៅឯកសារ “/foor/bar/t” ដែលមិនត្រឹមត្រូវ។
3. ស្ថានភាពចុងក្រោយមិនបានទៅដល់ផ្លូវមិនបានបញ្ចប់។ គ្មានបុព្វបទណាមួយត្រូវគ្នាជាមួយនេះទេ យើងមិនណែនាំការរឹតបន្តឹងទេ។

សេចក្តីសន្និដ្ឋាន

គោលដៅនៃដំណោះស្រាយសុវត្ថិភាពដែលកំពុងត្រូវបានបង្កើតឡើងគឺដើម្បីបង្កើនកម្រិតសុវត្ថិភាពរបស់អ្នកប្រើប្រាស់ និងទិន្នន័យរបស់គាត់។ ម៉្យាងវិញទៀត គោលដៅនេះត្រូវបានសម្រេចដោយការអភិវឌ្ឍន៍ផលិតផលកម្មវិធី Acronis ដែលបិទភាពងាយរងគ្រោះទាំងនោះ ដែលប្រព័ន្ធប្រតិបត្តិការខ្លួនឯង “ខ្សោយ”។ ម្យ៉ាងវិញទៀត យើងមិនគួរធ្វេសប្រហែសក្នុងការពង្រឹងផ្នែកសុវត្ថិភាពទាំងនោះ ដែលអាចធ្វើឱ្យប្រសើរឡើងនៅលើផ្នែក OS ជាពិសេសចាប់តាំងពីការបិទភាពងាយរងគ្រោះបែបនេះ បង្កើនស្ថេរភាពផ្ទាល់ខ្លួនរបស់យើងជាផលិតផល។ ភាពងាយរងគ្រោះត្រូវបានរាយការណ៍ទៅក្រុមសុវត្ថិភាពផលិតផល Apple ហើយត្រូវបានជួសជុលនៅក្នុង macOS 10.14.5 (https://support.apple.com/en-gb/HT210119)។

ទាំងអស់នេះអាចធ្វើបានលុះត្រាតែឧបករណ៍ប្រើប្រាស់របស់អ្នកត្រូវបានដំឡើងជាផ្លូវការទៅក្នុងខឺណែល។ នោះគឺមិនមានចន្លោះប្រហោងបែបនេះសម្រាប់កម្មវិធីខាងក្រៅ និងដែលមិនចង់បាននោះទេ។ ទោះជាយ៉ាងណាក៏ដោយ ដូចដែលអ្នកអាចមើលឃើញ សូម្បីតែការការពារកម្មវិធីស្របច្បាប់ដូចជាកំចាត់មេរោគ និងប្រព័ន្ធបម្រុងទុកក៏ទាមទារការងារដែរ។ ប៉ុន្តែឥឡូវនេះផលិតផល Acronis ថ្មីសម្រាប់ macOS នឹងមានការការពារបន្ថែមប្រឆាំងនឹងការផ្ទុកចេញពីប្រព័ន្ធ។

ប្រភព: www.habr.com