મેકઓએસ પર પ્રક્રિયાઓ અને કર્નલ એક્સ્ટેંશનને કેવી રીતે સુરક્ષિત કરવું

હેલો, હેબ્ર! આજે હું તે વિશે વાત કરવા માંગુ છું કે તમે કેવી રીતે macOS માં હુમલાખોરો દ્વારા હુમલાઓથી પ્રક્રિયાઓને સુરક્ષિત કરી શકો છો. ઉદાહરણ તરીકે, આ એન્ટીવાયરસ અથવા બેકઅપ સિસ્ટમ માટે ઉપયોગી છે, ખાસ કરીને કારણ કે macOS હેઠળ પ્રક્રિયાને "મારવા" માટે ઘણી રીતો છે. આ અને કટ હેઠળ રક્ષણ પદ્ધતિઓ વિશે વાંચો.

પ્રક્રિયાને "મારવા" માટેની ઉત્તમ રીત

પ્રક્રિયાને "મારવા" માટેની જાણીતી રીત એ પ્રક્રિયામાં સિગકિલ સિગ્નલ મોકલવાનો છે. bash દ્વારા તમે મારવા માટે માનક "kill -SIGKILL PID" અથવા "pkill -9 NAME" કૉલ કરી શકો છો. "કિલ" આદેશ UNIX ના દિવસોથી જાણીતો છે અને તે માત્ર macOS પર જ નહીં, પરંતુ અન્ય UNIX જેવી સિસ્ટમ્સ પર પણ ઉપલબ્ધ છે.

UNIX જેવી સિસ્ટમની જેમ, macOS તમને બે સિવાયની પ્રક્રિયામાં કોઈપણ સિગ્નલને અટકાવવાની મંજૂરી આપે છે - SIGKILL અને SIGSTOP. આ લેખ મુખ્યત્વે સિગ્નલ તરીકે SIGKILL સિગ્નલ પર ધ્યાન કેન્દ્રિત કરશે જે પ્રક્રિયાને મારી નાખવાનું કારણ બને છે.

macOS વિશિષ્ટતાઓ

macOS પર, XNU કર્નલમાં કિલ સિસ્ટમ કૉલ psignal(SIGKILL,...) ફંક્શનને કૉલ કરે છે. ચાલો એ જોવાનો પ્રયત્ન કરીએ કે યુઝરસ્પેસમાં અન્ય કઈ વપરાશકર્તા ક્રિયાઓને psignal ફંક્શન દ્વારા કહી શકાય. ચાલો કર્નલની આંતરિક મિકેનિઝમ્સમાં સિગ્નલ ફંક્શન માટેના કૉલ્સને નીંદણ કરીએ (જો કે તે બિન-તુચ્છ હોઈ શકે છે, અમે તેને બીજા લેખ માટે છોડીશું 🙂 - હસ્તાક્ષર ચકાસણી, મેમરી ભૂલો, એક્ઝિટ/ટર્મિનેટ હેન્ડલિંગ, ફાઇલ સંરક્ષણ ઉલ્લંઘન, વગેરે. .

ચાલો ફંક્શન અને અનુરૂપ સિસ્ટમ કૉલ સાથે સમીક્ષા શરૂ કરીએ ટર્મિનેટ_વિથ_પેલોડ. તે જોઈ શકાય છે કે ક્લાસિક કીલ કોલ ઉપરાંત, એક વૈકલ્પિક અભિગમ છે જે 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);
	}
...
}

લોન્ચ કર્યું

સિસ્ટમ સ્ટાર્ટઅપ પર ડિમન બનાવવાની અને તેમના જીવનકાળને નિયંત્રિત કરવાની પ્રમાણભૂત રીત શરૂ કરવામાં આવી છે. મહેરબાની કરીને નોંધ કરો કે સ્ત્રોતો macOS 10.10 સુધીના લોન્ચક્ટલના જૂના વર્ઝન માટે છે, કોડ ઉદાહરણો ઉદાહરણરૂપ હેતુઓ માટે પ્રદાન કરવામાં આવ્યા છે. આધુનિક લોન્ચસીટીએલ એક્સપીસી દ્વારા લોન્ચ સિગ્નલો મોકલે છે, લોન્ચસીટીએલ લોજીક તેમાં ખસેડવામાં આવ્યું છે.

ચાલો જોઈએ કે એપ્લિકેશનો કેવી રીતે બંધ થાય છે. 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 પણ મોકલી શકે છે.

પરોક્ષ કિલ - સંસાધન મર્યાદા

અન્ય સિસ્ટમ કૉલમાં વધુ રસપ્રદ કેસ જોઈ શકાય છે પ્રક્રિયા_નીતિ. આ સિસ્ટમ કોલનો સામાન્ય ઉપયોગ એપ્લીકેશન સંસાધનોને મર્યાદિત કરવાનો છે, જેમ કે ઇન્ડેક્સર માટે સીપીયુ સમય અને મેમરી ક્વોટાને મર્યાદિત કરવા માટે જેથી ફાઇલ કેશીંગ પ્રવૃત્તિઓ દ્વારા સિસ્ટમ નોંધપાત્ર રીતે ધીમું ન થાય. જો કોઈ એપ્લિકેશન તેની સંસાધન મર્યાદા સુધી પહોંચી ગઈ હોય, જેમ કે 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 પોલિસી રજીસ્ટર કરી શકાય છે, જે સિગ્નલ પ્રોટેક્શન મેથડ (પોલીસી proc_check_signal) પૂરી પાડે છે, પરંતુ API સત્તાવાર રીતે સપોર્ટેડ નથી.

કર્નલ એક્સ્ટેંશન રક્ષણ

સિસ્ટમમાં પ્રક્રિયાઓનું રક્ષણ કરવા ઉપરાંત, કર્નલ એક્સ્ટેંશન (kext)નું રક્ષણ કરવું પણ જરૂરી છે. macOS વિકાસકર્તાઓને IOKit ઉપકરણ ડ્રાઇવરોને સરળતાથી વિકસાવવા માટેનું માળખું પૂરું પાડે છે. ઉપકરણો સાથે કામ કરવા માટે સાધનો પૂરા પાડવા ઉપરાંત, IOKit C++ વર્ગોના ઉદાહરણોનો ઉપયોગ કરીને ડ્રાઇવર સ્ટેકીંગ માટેની પદ્ધતિઓ પ્રદાન કરે છે. યુઝરસ્પેસમાં એપ્લિકેશન કર્નલ-યુઝરસ્પેસ સંબંધ સ્થાપિત કરવા માટે વર્ગના રજિસ્ટર્ડ દાખલાને "શોધી" શકશે.

સિસ્ટમમાં વર્ગના દાખલાઓની સંખ્યા શોધવા માટે, ત્યાં ioclasscount ઉપયોગિતા છે.

my_kext_ioservice = 1
my_kext_iouserclient = 1

કોઈપણ કર્નલ એક્સ્ટેંશન કે જે ડ્રાઈવર સ્ટેક સાથે નોંધણી કરાવવા ઈચ્છે છે તેણે IOService માંથી વારસામાં મેળવેલા વર્ગની ઘોષણા કરવી જોઈએ, ઉદાહરણ તરીકે my_kext_ioservice આ કિસ્સામાં. વપરાશકર્તા એપ્લિકેશનોને કનેક્ટ કરવાથી વર્ગના નવા દાખલાની રચના થાય છે જે IOUserClient પાસેથી વારસામાં મળે છે, ઉદાહરણ તરીકે my_kext_iouserclient.

સિસ્ટમમાંથી ડ્રાઇવરને અનલોડ કરવાનો પ્રયાસ કરતી વખતે (kextunload આદેશ), વર્ચ્યુઅલ ફંક્શન "બૂલ ટર્મિનેટ(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/”) તમે નીચેના મેળવી શકો છો ડીએફએ. આકૃતિ ફક્ત અન્ય રાજ્યો તરફ દોરી જતા સંક્રમણો દર્શાવે છે; અન્ય સંક્રમણો અંતિમ રહેશે નહીં.

જ્યારે DKA રાજ્યોમાંથી પસાર થાય છે, ત્યાં 3 કેસ હોઈ શકે છે.

1. અંતિમ સ્થિતિ પહોંચી ગઈ છે - પાથ સુરક્ષિત છે, અમે KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA અને KAUTH_VNODE_DELETE_CHILD ઑપરેશન્સને મર્યાદિત કરીએ છીએ
2. અંતિમ સ્થિતિ સુધી પહોંચી ન હતી, પરંતુ પાથ “સમાપ્ત” (નલ ટર્મિનેટર પહોંચી ગયો હતો) - પાથ એ પેરેન્ટ છે, તે KAUTH_VNODE_DELETE ને મર્યાદિત કરવું જરૂરી છે. નોંધ કરો કે જો vnode એ ફોલ્ડર છે, તો તમારે અંતે '/' ઉમેરવાની જરૂર છે, અન્યથા તે તેને “/foor/bar/t” ફાઇલ સુધી મર્યાદિત કરી શકે છે, જે ખોટું છે.
3. અંતિમ અવસ્થા પર પહોંચી ન હતી, માર્ગ સમાપ્ત થયો ન હતો. કોઈપણ ઉપસર્ગ આ સાથે મેળ ખાતો નથી, અમે પ્રતિબંધો રજૂ કરતા નથી.

નિષ્કર્ષ

વિકસાવવામાં આવી રહેલા સુરક્ષા ઉકેલોનો ધ્યેય વપરાશકર્તા અને તેના ડેટાની સુરક્ષાના સ્તરને વધારવાનો છે. એક તરફ, આ ધ્યેય એક્રોનિસ સૉફ્ટવેર પ્રોડક્ટના વિકાસ દ્વારા પ્રાપ્ત થાય છે, જે તે નબળાઈઓને બંધ કરે છે જ્યાં ઑપરેટિંગ સિસ્ટમ પોતે "નબળી" છે. બીજી બાજુ, આપણે તે સુરક્ષા પાસાઓને મજબૂત બનાવવાની અવગણના ન કરવી જોઈએ જે OS બાજુએ સુધારી શકાય છે, ખાસ કરીને કારણ કે આવી નબળાઈઓને બંધ કરવાથી ઉત્પાદન તરીકે આપણી પોતાની સ્થિરતા વધે છે. નબળાઈની જાણ Apple ઉત્પાદન સુરક્ષા ટીમને કરવામાં આવી હતી અને તેને macOS 10.14.5 (https://support.apple.com/en-gb/HT210119) માં ઠીક કરવામાં આવી છે.

આ બધું ફક્ત ત્યારે જ થઈ શકે છે જો તમારી ઉપયોગિતા કર્નલમાં સત્તાવાર રીતે ઇન્સ્ટોલ કરવામાં આવી હોય. એટલે કે, બાહ્ય અને અનિચ્છનીય સોફ્ટવેર માટે આવી કોઈ છટકબારીઓ નથી. જો કે, તમે જોઈ શકો છો, એન્ટીવાયરસ અને બેકઅપ સિસ્ટમ્સ જેવા કાયદેસર પ્રોગ્રામ્સને સુરક્ષિત કરવા માટે પણ કાર્યની જરૂર છે. પરંતુ હવે macOS માટે નવા Acronis ઉત્પાદનોમાં સિસ્ટમમાંથી અનલોડિંગ સામે વધારાની સુરક્ષા હશે.

સોર્સ: www.habr.com