MacOSలో ప్రక్రియలు మరియు కెర్నల్ పొడిగింపులను ఎలా రక్షించాలి

హలో, హబ్ర్! MacOSలో దాడి చేసేవారి దాడుల నుండి మీరు ప్రాసెస్‌లను ఎలా రక్షించవచ్చనే దాని గురించి ఈ రోజు నేను మాట్లాడాలనుకుంటున్నాను. ఉదాహరణకు, ఇది యాంటీవైరస్ లేదా బ్యాకప్ సిస్టమ్‌కు ఉపయోగపడుతుంది, ప్రత్యేకించి MacOS కింద ప్రక్రియను "చంపడానికి" అనేక మార్గాలు ఉన్నాయి. కట్ కింద దీని గురించి మరియు రక్షణ పద్ధతుల గురించి చదవండి.

ప్రక్రియను "చంపడానికి" క్లాసిక్ మార్గం

ప్రక్రియను "చంపడానికి" బాగా తెలిసిన మార్గం ఏమిటంటే, ప్రక్రియకు SIGKILL సిగ్నల్ పంపడం. బాష్ ద్వారా మీరు చంపడానికి ప్రామాణిక “kill -SIGKILL PID” లేదా “pkill -9 NAME”ని కాల్ చేయవచ్చు. "కిల్" కమాండ్ UNIX రోజుల నుండి ప్రసిద్ది చెందింది మరియు ఇది మాకోస్‌లో మాత్రమే కాకుండా ఇతర UNIX-వంటి సిస్టమ్‌లలో కూడా అందుబాటులో ఉంది.

UNIX-వంటి సిస్టమ్‌లలో వలె, MacOS రెండు ప్రక్రియలకు తప్ప ఏవైనా సంకేతాలను అడ్డగించడానికి మిమ్మల్ని అనుమతిస్తుంది - SIGKILL మరియు SIGSTOP. ఈ కథనం ప్రాథమికంగా SIGKILL సిగ్నల్‌పై దృష్టి సారిస్తుంది, ఇది ప్రక్రియను చంపడానికి కారణమవుతుంది.

macOS ప్రత్యేకతలు

MacOSలో, XNU కెర్నల్‌లోని కిల్ సిస్టమ్ కాల్ psignal(SIGKILL,...) ఫంక్షన్‌ని పిలుస్తుంది. యూజర్‌స్పేస్‌లోని ఇతర వినియోగదారు చర్యలను పిసిగ్నల్ ఫంక్షన్ ద్వారా ఏమని పిలవవచ్చో చూడటానికి ప్రయత్నిద్దాం. కెర్నల్ యొక్క అంతర్గత మెకానిజమ్స్‌లోని పిసిగ్నల్ ఫంక్షన్‌కు కాల్‌లను కలుపుదాం (అవి చిన్నవిషయం కానప్పటికీ, మేము వాటిని మరొక కథనం కోసం వదిలివేస్తాము 🙂 - సంతకం ధృవీకరణ, మెమరీ లోపాలు, నిష్క్రమణ/నిర్వహణను ముగించడం, ఫైల్ రక్షణ ఉల్లంఘనలు, మొదలైనవి

ఫంక్షన్ మరియు సంబంధిత సిస్టమ్ కాల్‌తో సమీక్షను ప్రారంభిద్దాం టర్మినేట్_విత్_పేలోడ్. క్లాసిక్ కిల్ కాల్‌తో పాటు, MacOS ఆపరేటింగ్ సిస్టమ్‌కు ప్రత్యేకమైన మరియు BSDలో కనిపించని ప్రత్యామ్నాయ విధానం కూడా ఉందని చూడవచ్చు. రెండు సిస్టమ్ కాల్‌ల ఆపరేటింగ్ సూత్రాలు కూడా సమానంగా ఉంటాయి. అవి కెర్నల్ ఫంక్షన్ psignalకు డైరెక్ట్ కాల్స్. ఒక ప్రాసెస్‌ను చంపే ముందు, "కాన్సిగ్నల్" చెక్ నిర్వహించబడుతుందని గమనించండి - ప్రక్రియ మరొక ప్రక్రియకు సిగ్నల్‌ను పంపగలదా; సిస్టమ్ ప్రాసెస్‌లను చంపడానికి సిస్టమ్ ఏ అప్లికేషన్‌ను అనుమతించదు, ఉదాహరణకు.

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);
	}
...
}

ప్రయోగించారు

సిస్టమ్ ప్రారంభంలో డెమోన్‌లను సృష్టించడానికి మరియు వారి జీవితకాలాన్ని నియంత్రించడానికి ప్రామాణిక మార్గం ప్రారంభించబడింది. దయచేసి మూలాలు మాకోస్ 10.10 వరకు లాంచ్‌క్ట్ల్ యొక్క పాత వెర్షన్‌కు సంబంధించినవని గమనించండి, కోడ్ ఉదాహరణలు సచిత్ర ప్రయోజనాల కోసం అందించబడ్డాయి. ఆధునిక లాంచ్‌క్ట్ల్ XPC ద్వారా లాంచ్డ్ సిగ్నల్‌లను పంపుతుంది, లాంచ్‌క్ట్ల్ లాజిక్ దానికి తరలించబడింది.

అప్లికేషన్లు ఎలా ఆపివేయబడతాయో చూద్దాం. 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తో మాత్రమే కాకుండా SIGKILLని కూడా పంపవచ్చు.

పరోక్ష హత్య - వనరుల పరిమితి

మరొక సిస్టమ్ కాల్‌లో మరింత ఆసక్తికరమైన సందర్భాన్ని చూడవచ్చు ప్రక్రియ_విధానం. ఈ సిస్టమ్ కాల్ యొక్క సాధారణ ఉపయోగం అనువర్తన వనరులను పరిమితం చేయడం, ఉదాహరణకు ఒక సూచిక CPU సమయం మరియు మెమరీ కోటాలను పరిమితం చేయడం, తద్వారా సిస్టమ్ ఫైల్ కాషింగ్ కార్యకలాపాల ద్వారా గణనీయంగా మందగించబడదు. ఒక అప్లికేషన్ దాని వనరుల పరిమితిని చేరుకున్నట్లయితే, proc_apply_resource_actions ఫంక్షన్ నుండి చూడవచ్చు, ప్రాసెస్‌కి SIGKILL సిగ్నల్ పంపబడుతుంది.

ఈ సిస్టమ్ కాల్ ప్రాసెస్‌ను చంపే అవకాశం ఉన్నప్పటికీ, సిస్టమ్ కాల్‌కి కాల్ చేసే ప్రక్రియ యొక్క హక్కులను సిస్టమ్ తగినంతగా తనిఖీ చేయలేదు. వాస్తవానికి తనిఖీ చేస్తోంది ఉనికిలో ఉంది, కానీ ఈ షరతును దాటవేయడానికి ప్రత్యామ్నాయ ఫ్లాగ్ PROC_POLICY_ACTION_SETని ఉపయోగిస్తే సరిపోతుంది.

అందువల్ల, మీరు అప్లికేషన్ యొక్క CPU వినియోగ కోటాను "పరిమితం" చేస్తే (ఉదాహరణకు, 1 ns మాత్రమే అమలు చేయడానికి అనుమతిస్తుంది), అప్పుడు మీరు సిస్టమ్‌లోని ఏదైనా ప్రక్రియను నాశనం చేయవచ్చు. అందువలన, మాల్వేర్ యాంటీవైరస్ ప్రక్రియతో సహా సిస్టమ్‌లోని ఏదైనా ప్రక్రియను నాశనం చేయగలదు. పిడ్ 1 (లాంచ్‌క్ట్‌ఎల్)తో ప్రక్రియను చంపినప్పుడు సంభవించే ప్రభావం కూడా ఆసక్తికరంగా ఉంటుంది - సిగ్‌కిల్ సిగ్నల్‌ను ప్రాసెస్ చేయడానికి ప్రయత్నిస్తున్నప్పుడు కెర్నల్ భయాందోళన :)

సమస్యను ఎలా పరిష్కరించాలి?

సిస్టమ్ కాల్ టేబుల్‌లోని ఫంక్షన్ పాయింటర్‌ను భర్తీ చేయడం అనేది ప్రక్రియను చంపకుండా నిరోధించడానికి అత్యంత సరళమైన మార్గం. దురదృష్టవశాత్తు, ఈ పద్ధతి అనేక కారణాల వల్ల సామాన్యమైనది కాదు.

ముందుగా, 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ని అందిస్తుంది. ఎండ్‌పాయింట్ సెక్యూరిటీ 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;
}

అదేవిధంగా, ఒక MAC పాలసీని కెర్నల్‌లో నమోదు చేయవచ్చు, ఇది సిగ్నల్ రక్షణ పద్ధతిని అందిస్తుంది (policy proc_check_signal), కానీ APIకి అధికారికంగా మద్దతు లేదు.

కెర్నల్ పొడిగింపు రక్షణ

సిస్టమ్‌లోని ప్రక్రియలను రక్షించడంతో పాటు, కెర్నల్ పొడిగింపును రక్షించడం (కెక్స్ట్) కూడా అవసరం. MacOS IOKit పరికర డ్రైవర్లను సులభంగా అభివృద్ధి చేయడానికి డెవలపర్‌లకు ఫ్రేమ్‌వర్క్‌ను అందిస్తుంది. పరికరాలతో పని చేయడానికి సాధనాలను అందించడంతో పాటు, IOKit C++ తరగతుల ఉదాహరణలను ఉపయోగించి డ్రైవర్ స్టాకింగ్ కోసం పద్ధతులను అందిస్తుంది. యూజర్‌స్పేస్‌లోని అప్లికేషన్ కెర్నల్-యూజర్‌స్పేస్ సంబంధాన్ని ఏర్పరచడానికి తరగతి యొక్క నమోదిత ఉదాహరణను "కనుగొనగలదు".

సిస్టమ్‌లోని క్లాస్ ఇన్‌స్టాన్స్‌ల సంఖ్యను గుర్తించడానికి, ఐయోక్లాస్‌కౌంట్ యుటిలిటీ ఉంది.

my_kext_ioservice = 1
my_kext_iouserclient = 1

డ్రైవర్ స్టాక్‌తో నమోదు చేసుకోవాలనుకునే ఏదైనా కెర్నల్ పొడిగింపు తప్పనిసరిగా IOService నుండి వారసత్వంగా పొందే తరగతిని ప్రకటించాలి, ఉదాహరణకు my_kext_ioservice ఈ సందర్భంలో. వినియోగదారు అప్లికేషన్‌లను కనెక్ట్ చేయడం వలన IOUserClient నుండి వారసత్వంగా పొందిన తరగతి యొక్క కొత్త ఉదాహరణను సృష్టించడం జరుగుతుంది, ఉదాహరణకు my_kext_iouserclient.

సిస్టమ్ నుండి డ్రైవర్‌ను అన్‌లోడ్ చేయడానికి ప్రయత్నిస్తున్నప్పుడు (kextunload కమాండ్), వర్చువల్ ఫంక్షన్ “bool terminate(IOOptionBits ఎంపికలు)” అంటారు. కెక్స్‌టన్‌లోడ్‌ని నిలిపివేయడానికి అన్‌లోడ్ చేయడానికి ప్రయత్నిస్తున్నప్పుడు ముగించడానికి కాల్‌లో ఫాల్స్‌ని తిరిగి ఇస్తే సరిపోతుంది.

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 ఫ్లాగ్, io_name_t డిస్క్రిప్షన్)”ని ఉపయోగించి క్లాస్‌ల ఉదాహరణలు అన్‌లోడ్ చేయబడతాయి. యూజర్‌స్పేస్ అప్లికేషన్ “డైస్” అయ్యే వరకు “టర్మినేట్” కమాండ్‌ను కాల్ చేస్తున్నప్పుడు మీరు తప్పుని తిరిగి ఇవ్వవచ్చు, అంటే “క్లయింట్‌డైడ్” ఫంక్షన్ కాల్ చేయబడదు.

ఫైల్ రక్షణ

ఫైల్‌లను రక్షించడానికి, Kauth APIని ఉపయోగించడం సరిపోతుంది, ఇది ఫైల్‌లకు ప్రాప్యతను పరిమితం చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. Apple పరిధిలోని వివిధ ఈవెంట్‌ల గురించి డెవలపర్‌లకు నోటిఫికేషన్‌లను అందిస్తుంది; మాకు, KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA మరియు KAUTH_VNODE_DELETE_CHILD కార్యకలాపాలు ముఖ్యమైనవి. ఫైల్‌లకు ప్రాప్యతను పరిమితం చేయడానికి సులభమైన మార్గం మార్గం ద్వారా - మేము ఫైల్‌కు మార్గాన్ని పొందడానికి మరియు పాత్ ప్రిఫిక్స్‌ను సరిపోల్చడానికి “vn_getpath” APIని ఉపయోగిస్తాము. ఫైల్ ఫోల్డర్ పాత్‌ల పేరు మార్చడాన్ని ఆప్టిమైజ్ చేయడానికి, సిస్టమ్ ప్రతి ఫైల్‌కు యాక్సెస్‌ను ప్రామాణీకరించదు, కానీ పేరు మార్చబడిన ఫోల్డర్‌కు మాత్రమే. పేరెంట్ పాత్‌ను సరిపోల్చడం మరియు దాని కోసం KAUTH_VNODE_DELETEని పరిమితం చేయడం అవసరం.

ఉపసర్గల సంఖ్య పెరిగినందున ఈ విధానం యొక్క ప్రతికూలత తక్కువ పనితీరు కావచ్చు. పోలిక O(ఉపసర్గ*పొడవు)కి సమానంగా లేదని నిర్ధారించుకోవడానికి, ఉపసర్గ అంటే ఉపసర్గల సంఖ్య, పొడవు అనేది స్ట్రింగ్ యొక్క పొడవు, మీరు ఉపసర్గల ద్వారా రూపొందించబడిన నిర్ణీత పరిమిత ఆటోమేటన్ (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. చివరి స్థితికి చేరుకోలేదు, కానీ మార్గం “ముగిసిపోయింది” (శూన్య టెర్మినేటర్ చేరుకుంది) - మార్గం పేరెంట్, ఇది KAUTH_VNODE_DELETEని పరిమితం చేయడం అవసరం. vnode ఒక ఫోల్డర్ అయితే, మీరు చివరలో '/'ని జోడించాలి, లేకుంటే అది "/for/bar/t" ఫైల్‌కి పరిమితం చేయబడవచ్చు, అది తప్పు.
3. అంతిమ స్థితికి చేరుకోలేదు, మార్గం అంతం కాలేదు. ఉపసర్గలు ఏవీ దీనికి సరిపోలలేదు, మేము పరిమితులను ప్రవేశపెట్టము.

తీర్మానం

అభివృద్ధి చేయబడిన భద్రతా పరిష్కారాల లక్ష్యం వినియోగదారు మరియు అతని డేటా యొక్క భద్రత స్థాయిని పెంచడం. ఒక వైపు, ఈ లక్ష్యం అక్రోనిస్ సాఫ్ట్‌వేర్ ఉత్పత్తి అభివృద్ధి ద్వారా సాధించబడుతుంది, ఇది ఆపరేటింగ్ సిస్టమ్ "బలహీనంగా" ఉన్న ఆ దుర్బలత్వాలను మూసివేస్తుంది. మరోవైపు, OS వైపు మెరుగుపరచగల భద్రతా అంశాలను బలోపేతం చేయడాన్ని మేము విస్మరించకూడదు, ప్రత్యేకించి అటువంటి దుర్బలత్వాలను మూసివేయడం వలన ఉత్పత్తిగా మన స్వంత స్థిరత్వం పెరుగుతుంది. దుర్బలత్వం Apple ఉత్పత్తి భద్రతా బృందానికి నివేదించబడింది మరియు macOS 10.14.5 (https://support.apple.com/en-gb/HT210119)లో పరిష్కరించబడింది.

మీ యుటిలిటీ అధికారికంగా కెర్నల్‌లో ఇన్‌స్టాల్ చేయబడి ఉంటే మాత్రమే ఇవన్నీ చేయవచ్చు. అంటే, బాహ్య మరియు అవాంఛిత సాఫ్ట్‌వేర్‌లకు అలాంటి లొసుగులు లేవు. అయినప్పటికీ, మీరు చూడగలిగినట్లుగా, యాంటీవైరస్ మరియు బ్యాకప్ సిస్టమ్‌ల వంటి చట్టబద్ధమైన ప్రోగ్రామ్‌లను రక్షించడానికి కూడా పని అవసరం. కానీ ఇప్పుడు MacOS కోసం కొత్త Acronis ఉత్పత్తులు సిస్టమ్ నుండి అన్‌లోడ్ చేయకుండా అదనపు రక్షణను కలిగి ఉంటాయి.

మూలం: www.habr.com