🥇MacOS-ൽ പ്രോസസ്സുകളും കേർണൽ എക്സ്റ്റൻഷനുകളും എങ്ങനെ സംരക്ഷിക്കാം

ഹലോ, ഹബ്ർ! MacOS-ലെ ആക്രമണകാരികളുടെ ആക്രമണങ്ങളിൽ നിന്ന് നിങ്ങൾക്ക് പ്രക്രിയകളെ എങ്ങനെ സംരക്ഷിക്കാം എന്നതിനെക്കുറിച്ച് ഇന്ന് സംസാരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. ഉദാഹരണത്തിന്, ഇത് ഒരു ആന്റിവൈറസിനോ ബാക്കപ്പ് സിസ്റ്റത്തിനോ ഉപയോഗപ്രദമാണ്, പ്രത്യേകിച്ചും MacOS-ന് കീഴിൽ ഒരു പ്രക്രിയയെ "കൊല്ലാൻ" നിരവധി മാർഗങ്ങളുണ്ട്. ഇതിനെക്കുറിച്ചും കട്ടിന് കീഴിലുള്ള സംരക്ഷണ രീതികളെക്കുറിച്ചും വായിക്കുക.

ഒരു പ്രക്രിയയെ "കൊല്ലാനുള്ള" ക്ലാസിക് മാർഗം

ഒരു പ്രക്രിയയെ "കൊല്ലാൻ" അറിയപ്പെടുന്ന ഒരു മാർഗ്ഗം, പ്രോസസ്സിലേക്ക് ഒരു SIGKILL സിഗ്നൽ അയയ്ക്കുക എന്നതാണ്. ബാഷിലൂടെ നിങ്ങൾക്ക് കൊല്ലാൻ സ്റ്റാൻഡേർഡ് “kill -SIGKILL PID” അല്ലെങ്കിൽ “pkill -9 NAME” എന്ന് വിളിക്കാം. "കിൽ" കമാൻഡ് UNIX-ന്റെ കാലം മുതൽ അറിയപ്പെടുന്നു, ഇത് macOS-ൽ മാത്രമല്ല, മറ്റ് UNIX-പോലുള്ള സിസ്റ്റങ്ങളിലും ലഭ്യമാണ്.

യുണിക്‌സ് പോലുള്ള സിസ്റ്റങ്ങളിലെന്നപോലെ, സിഗ്‌കിൽ, സിഗ്‌സ്റ്റോപ്പ് എന്നിവ ഒഴികെയുള്ള ഒരു പ്രക്രിയയിലേക്കുള്ള സിഗ്നലുകളെ തടസ്സപ്പെടുത്താൻ macOS നിങ്ങളെ അനുവദിക്കുന്നു. ഈ ലേഖനം പ്രാഥമികമായി SIGKILL സിഗ്നലിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കും, അത് ഒരു പ്രക്രിയയെ നശിപ്പിക്കാൻ കാരണമാകുന്നു.

macOS പ്രത്യേകതകൾ

MacOS-ൽ, XNU കേർണലിലെ കിൽ സിസ്റ്റം കോൾ psignal(SIGKILL,...) ഫംഗ്‌ഷനെ വിളിക്കുന്നു. ഉപയോക്തൃസ്‌പേസിലെ മറ്റ് ഉപയോക്തൃ പ്രവർത്തനങ്ങളെ സിഗ്നൽ ഫംഗ്‌ഷൻ എന്ന് വിളിക്കാമെന്ന് നോക്കാം. കേർണലിന്റെ ആന്തരിക മെക്കാനിസങ്ങളിലെ സിഗ്നൽ ഫംഗ്‌ഷനിലേക്കുള്ള കോളുകൾ നമുക്ക് ഒഴിവാക്കാം (അവ നിസ്സാരമല്ലെങ്കിലും, ഞങ്ങൾ അവയെ മറ്റൊരു ലേഖനത്തിനായി വിടും 🙂 - ഒപ്പ് പരിശോധന, മെമ്മറി പിശകുകൾ, എക്‌സിറ്റ്/ടെർമിനേറ്റ് ഹാൻഡ്‌ലിംഗ്, ഫയൽ സംരക്ഷണ ലംഘനങ്ങൾ മുതലായവ. .

പ്രവർത്തനവും അനുബന്ധ സിസ്റ്റം കോളും ഉപയോഗിച്ച് അവലോകനം ആരംഭിക്കാം ടെർമിനേറ്റ്_വിത്ത്_പേലോഡ്. ക്ലാസിക് കിൽ കോളിന് പുറമേ, MacOS ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന് പ്രത്യേകമായ ഒരു ബദൽ സമീപനവും BSD-യിൽ കാണാനാകില്ല. രണ്ട് സിസ്റ്റം കോളുകളുടെയും പ്രവർത്തന തത്വങ്ങളും സമാനമാണ്. കേർണൽ ഫംഗ്‌ഷൻ സിഗ്നലിലേക്കുള്ള നേരിട്ടുള്ള കോളുകളാണ് അവ. ഒരു പ്രോസസ്സ് ഇല്ലാതാക്കുന്നതിന് മുമ്പ്, ഒരു "കാൻസിഗ്നൽ" പരിശോധന നടത്തുന്നു - പ്രക്രിയയ്ക്ക് മറ്റൊരു പ്രക്രിയയിലേക്ക് ഒരു സിഗ്നൽ അയയ്‌ക്കാൻ കഴിയുമോ; സിസ്റ്റം പ്രോസസ്സുകളെ നശിപ്പിക്കാൻ ഒരു ആപ്ലിക്കേഷനെയും സിസ്റ്റം അനുവദിക്കുന്നില്ല, ഉദാഹരണത്തിന്.

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 വരെയുള്ള launchctl-ന്റെ പഴയ പതിപ്പിനാണ് ഉറവിടങ്ങൾ എന്ന കാര്യം ശ്രദ്ധിക്കുക, കോഡ് ഉദാഹരണങ്ങൾ ചിത്രീകരണ ആവശ്യങ്ങൾക്കായി നൽകിയിരിക്കുന്നു. ആധുനിക ലോഞ്ച്‌ക്‌എൽ എക്സ്‌പിസി വഴി ലോഞ്ച് ചെയ്‌ത സിഗ്നലുകൾ അയയ്‌ക്കുന്നു, ലോഞ്ച്ക്‌എൽ ലോജിക് അതിലേക്ക് നീക്കി.

ആപ്ലിക്കേഷനുകൾ കൃത്യമായി നിർത്തുന്നത് എങ്ങനെയെന്ന് നോക്കാം. 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-നും അയയ്ക്കാൻ കഴിയും.

പരോക്ഷ കിൽ - റിസോഴ്സ് പരിധി

മറ്റൊരു സിസ്റ്റം കോളിൽ കൂടുതൽ രസകരമായ ഒരു കേസ് കാണാം പ്രക്രിയ_നയം. ഫയൽ കാഷിംഗ് പ്രവർത്തനങ്ങളാൽ സിസ്റ്റം ഗണ്യമായി മന്ദഗതിയിലാകാതിരിക്കാൻ, സിപിയു സമയവും മെമ്മറി ക്വാട്ടയും പരിമിതപ്പെടുത്തുന്നതിന് ഒരു സൂചികയ്ക്ക് വേണ്ടിയുള്ള ആപ്ലിക്കേഷൻ ഉറവിടങ്ങൾ പരിമിതപ്പെടുത്തുക എന്നതാണ് ഈ സിസ്റ്റം കോളിന്റെ പൊതുവായ ഉപയോഗം. ഒരു ആപ്ലിക്കേഷൻ അതിന്റെ റിസോഴ്സ് പരിധിയിൽ എത്തിയിട്ടുണ്ടെങ്കിൽ, 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-ന്റെ ആധുനിക പതിപ്പുകളിൽ, പ്രോസസുകളിൽ പ്രവർത്തിക്കുന്നതിന് ആപ്പിൾ ഒരു പുതിയ 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;
}

അതുപോലെ, ഒരു സിഗ്നൽ പരിരക്ഷണ രീതി (policy proc_check_signal) നൽകുന്ന കേർണലിൽ ഒരു MAC പോളിസി രജിസ്റ്റർ ചെയ്യാവുന്നതാണ്, എന്നാൽ API ഔദ്യോഗികമായി പിന്തുണയ്ക്കുന്നില്ല.

കേർണൽ വിപുലീകരണ സംരക്ഷണം

സിസ്റ്റത്തിലെ പ്രക്രിയകൾ സംരക്ഷിക്കുന്നതിനു പുറമേ, കേർണൽ എക്സ്റ്റൻഷൻ തന്നെ (കെക്സ്റ്റ്) സംരക്ഷിക്കേണ്ടതും ആവശ്യമാണ്. ഡെവലപ്പർമാർക്ക് IOKit ഡിവൈസ് ഡ്രൈവറുകൾ എളുപ്പത്തിൽ വികസിപ്പിക്കുന്നതിനുള്ള ഒരു ചട്ടക്കൂട് macOS നൽകുന്നു. ഉപകരണങ്ങളുമായി പ്രവർത്തിക്കുന്നതിനുള്ള ടൂളുകൾ നൽകുന്നതിനു പുറമേ, C++ ക്ലാസുകളുടെ ഉദാഹരണങ്ങൾ ഉപയോഗിച്ച് IOKit ഡ്രൈവർ സ്റ്റാക്കിംഗ് രീതികൾ നൽകുന്നു. ഒരു കേർണൽ-ഉപയോക്തൃസ്‌പേസ് ബന്ധം സ്ഥാപിക്കുന്നതിന് ക്ലാസ്സിന്റെ രജിസ്റ്റർ ചെയ്ത ഉദാഹരണം "കണ്ടെത്താൻ" യൂസർസ്‌പേസിലെ ഒരു ആപ്ലിക്കേഷന് കഴിയും.

സിസ്റ്റത്തിലെ ക്ലാസ് ഇൻസ്‌റ്റൻസുകളുടെ എണ്ണം കണ്ടെത്തുന്നതിന്, ioclasscount യൂട്ടിലിറ്റി ഉണ്ട്.

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

ലോഡുചെയ്യുമ്പോൾ IOUserClient-ന് IsUnloadAllowed ഫ്ലാഗ് സജ്ജീകരിക്കാനാകും. ഒരു ഡൗൺലോഡ് പരിധി ഉള്ളപ്പോൾ, 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-ന് സമാനമായ സംരക്ഷണം നൽകണം. "IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t description);" IOKitLib ഉപയോക്തൃസ്‌പേസ് ഫംഗ്‌ഷൻ ഉപയോഗിച്ച് ക്ലാസുകളുടെ ഉദാഹരണങ്ങൾ അൺലോഡ് ചെയ്യാൻ കഴിയും. "ടെർമിനേറ്റ്" കമാൻഡ് വിളിക്കുമ്പോൾ നിങ്ങൾക്ക് തെറ്റായി നൽകാം, ഉപയോക്തൃസ്പേസ് ആപ്ലിക്കേഷൻ "ഡെയ്സ്" വരെ, അതായത്, "ക്ലയന്റ് ഡൈഡ്" ഫംഗ്ഷൻ വിളിക്കപ്പെടില്ല.

ഫയൽ സംരക്ഷണം

ഫയലുകൾ പരിരക്ഷിക്കുന്നതിന്, ഫയലുകളിലേക്കുള്ള ആക്സസ് നിയന്ത്രിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന Kauth API ഉപയോഗിച്ചാൽ മതിയാകും. വ്യത്യസ്‌ത പരിപാടികളെക്കുറിച്ചുള്ള അറിയിപ്പുകൾ ആപ്പിൾ ഡെവലപ്പർമാർക്ക് നൽകുന്നു; ഞങ്ങളെ സംബന്ധിച്ചിടത്തോളം, KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA, KAUTH_VNODE_DELETE_CHILD എന്നീ പ്രവർത്തനങ്ങൾ പ്രധാനമാണ്. ഫയലുകളിലേക്കുള്ള ആക്‌സസ് പരിമിതപ്പെടുത്താനുള്ള ഏറ്റവും എളുപ്പ മാർഗം പാത്ത് വഴിയാണ് - ഫയലിലേക്കുള്ള പാത്ത് ലഭിക്കുന്നതിനും പാത്ത് പ്രിഫിക്‌സ് താരതമ്യം ചെയ്യുന്നതിനും ഞങ്ങൾ “vn_getpath” API ഉപയോഗിക്കുന്നു. ഫയൽ ഫോൾഡർ പാഥുകളുടെ പുനർനാമകരണം ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിന്, സിസ്റ്റം ഓരോ ഫയലിലേക്കും പ്രവേശനം അനുവദിക്കുന്നില്ല, മറിച്ച് പേരുമാറ്റിയ ഫോൾഡറിലേക്ക് മാത്രമാണ്. പാരന്റ് പാത്ത് താരതമ്യം ചെയ്യുകയും അതിനായി KAUTH_VNODE_DELETE പരിമിതപ്പെടുത്തുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്.

പ്രിഫിക്സുകളുടെ എണ്ണം വർദ്ധിക്കുന്നതിനാൽ ഈ സമീപനത്തിന്റെ പോരായ്മ കുറഞ്ഞ പ്രകടനമായിരിക്കാം. പ്രിഫിക്‌സ് എന്നത് പ്രിഫിക്‌സുകളുടെ എണ്ണവും നീളം എന്നത് സ്‌ട്രിംഗിന്റെ നീളവും ആയ O(പ്രിഫിക്‌സ്*ദൈർഘ്യത്തിന്) തുല്യമല്ല താരതമ്യമെന്ന് ഉറപ്പാക്കാൻ, നിങ്ങൾക്ക് പ്രിഫിക്‌സുകളാൽ നിർമ്മിച്ച ഒരു ഡിറ്റർമിനിസ്റ്റിക് ഫിനിറ്റ് ഓട്ടോമാറ്റൺ (DFA) ഉപയോഗിക്കാം.

നൽകിയിരിക്കുന്ന ഒരു കൂട്ടം പ്രിഫിക്സുകൾക്കായി ഒരു ഡിഎഫ്എ നിർമ്മിക്കുന്നതിനുള്ള ഒരു രീതി നമുക്ക് പരിഗണിക്കാം. ഓരോ പ്രിഫിക്‌സിന്റെയും തുടക്കത്തിൽ ഞങ്ങൾ കഴ്‌സറുകൾ സമാരംഭിക്കുന്നു. എല്ലാ കഴ്‌സറുകളും ഒരേ പ്രതീകത്തിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്നുവെങ്കിൽ, ഓരോ കഴ്‌സറും ഒരു പ്രതീകം കൊണ്ട് വർദ്ധിപ്പിക്കുകയും അതേ വരിയുടെ നീളം ഒന്നായി കൂടുതലാണെന്ന് ഓർമ്മിക്കുക. വ്യത്യസ്‌ത ചിഹ്നങ്ങളുള്ള രണ്ട് കഴ്‌സറുകൾ ഉണ്ടെങ്കിൽ, അവർ ചൂണ്ടിക്കാണിക്കുന്ന ചിഹ്നമനുസരിച്ച് കഴ്‌സറുകളെ ഗ്രൂപ്പുകളായി വിഭജിച്ച് ഓരോ ഗ്രൂപ്പിനും അൽഗോരിതം ആവർത്തിക്കുക.

ആദ്യ സന്ദർഭത്തിൽ (കർസറുകൾക്ക് കീഴിലുള്ള എല്ലാ പ്രതീകങ്ങളും ഒന്നുതന്നെയാണ്), ഒരേ ലൈനിലൂടെ ഒരു പരിവർത്തനം മാത്രമുള്ള ഒരു DFA അവസ്ഥ നമുക്ക് ലഭിക്കും. രണ്ടാമത്തെ സാഹചര്യത്തിൽ, ഫംഗ്‌ഷനെ ആവർത്തിച്ച് വിളിക്കുന്നതിലൂടെ ലഭിക്കുന്ന തുടർന്നുള്ള അവസ്ഥകളിലേക്കുള്ള 256 വലുപ്പത്തിന്റെ (അക്ഷരങ്ങളുടെ എണ്ണവും പരമാവധി ഗ്രൂപ്പുകളുടെ എണ്ണവും) സംക്രമണങ്ങളുടെ ഒരു പട്ടിക നമുക്ക് ലഭിക്കും.

നമുക്ക് ഒരു ഉദാഹരണം നോക്കാം. ഒരു കൂട്ടം പ്രിഫിക്സുകൾക്കായി (“/foo/bar/tmp/”, “/var/db/foo/”, “/foo/bar/aba/”, “foo/bar/aac/”) നിങ്ങൾക്ക് ഇനിപ്പറയുന്നവ ലഭിക്കും ഡിഎഫ്എ. മറ്റ് സംസ്ഥാനങ്ങളിലേക്ക് നയിക്കുന്ന പരിവർത്തനങ്ങൾ മാത്രമാണ് ചിത്രം കാണിക്കുന്നത്; മറ്റ് പരിവർത്തനങ്ങൾ അന്തിമമായിരിക്കില്ല.

DKA സംസ്ഥാനങ്ങളിലൂടെ പോകുമ്പോൾ, 3 കേസുകൾ ഉണ്ടാകാം.

അന്തിമ അവസ്ഥയിൽ എത്തി - പാത പരിരക്ഷിക്കപ്പെട്ടിരിക്കുന്നു, KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA, KAUTH_VNODE_DELETE_CHILD എന്നീ പ്രവർത്തനങ്ങൾ ഞങ്ങൾ പരിമിതപ്പെടുത്തുന്നു
അന്തിമ അവസ്ഥയിൽ എത്തിയില്ല, പക്ഷേ പാത "അവസാനിച്ചു" (നൾ ടെർമിനേറ്ററിൽ എത്തി) - പാത ഒരു രക്ഷിതാവാണ്, KAUTH_VNODE_DELETE പരിമിതപ്പെടുത്തേണ്ടത് ആവശ്യമാണ്. vnode ഒരു ഫോൾഡറാണെങ്കിൽ, നിങ്ങൾ അവസാനം ഒരു '/' ചേർക്കേണ്ടതുണ്ട്, അല്ലാത്തപക്ഷം അത് "/for/bar/t" എന്ന ഫയലിലേക്ക് പരിമിതപ്പെടുത്തിയേക്കാം, അത് തെറ്റാണ്.
അന്തിമ അവസ്ഥയിൽ എത്തിയില്ല, പാത അവസാനിച്ചില്ല. പ്രിഫിക്‌സുകളൊന്നും ഇതുമായി പൊരുത്തപ്പെടുന്നില്ല, ഞങ്ങൾ നിയന്ത്രണങ്ങൾ അവതരിപ്പിക്കുന്നില്ല.

തീരുമാനം

വികസിപ്പിച്ചുകൊണ്ടിരിക്കുന്ന സുരക്ഷാ പരിഹാരങ്ങളുടെ ലക്ഷ്യം ഉപയോക്താവിന്റെയും അവന്റെ ഡാറ്റയുടെയും സുരക്ഷയുടെ നിലവാരം വർദ്ധിപ്പിക്കുക എന്നതാണ്. ഒരു വശത്ത്, അക്രോണിസ് സോഫ്റ്റ്വെയർ ഉൽപ്പന്നത്തിന്റെ വികസനം വഴി ഈ ലക്ഷ്യം കൈവരിക്കുന്നു, അത് ഓപ്പറേറ്റിംഗ് സിസ്റ്റം തന്നെ "ദുർബലമായ" ആ കേടുപാടുകൾ അടയ്ക്കുന്നു. മറുവശത്ത്, OS വശത്ത് മെച്ചപ്പെടുത്താൻ കഴിയുന്ന സുരക്ഷാ വശങ്ങൾ ശക്തിപ്പെടുത്തുന്നത് ഞങ്ങൾ അവഗണിക്കരുത്, പ്രത്യേകിച്ചും അത്തരം കേടുപാടുകൾ അടയ്ക്കുന്നത് ഒരു ഉൽപ്പന്നമെന്ന നിലയിൽ നമ്മുടെ സ്വന്തം സ്ഥിരത വർദ്ധിപ്പിക്കുന്നതിനാൽ. അപകടസാധ്യത Apple Product Security Team-ന് റിപ്പോർട്ട് ചെയ്തു, macOS 10.14.5 (https://support.apple.com/en-gb/HT210119)-ൽ അത് പരിഹരിച്ചു.

നിങ്ങളുടെ യൂട്ടിലിറ്റി ഔദ്യോഗികമായി കേർണലിൽ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടെങ്കിൽ മാത്രമേ ഇതെല്ലാം ചെയ്യാൻ കഴിയൂ. അതായത്, ബാഹ്യവും ആവശ്യമില്ലാത്തതുമായ സോഫ്‌റ്റ്‌വെയറുകൾക്ക് അത്തരം പഴുതുകളൊന്നുമില്ല. എന്നിരുന്നാലും, നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ആന്റിവൈറസും ബാക്കപ്പ് സിസ്റ്റങ്ങളും പോലുള്ള നിയമാനുസൃത പ്രോഗ്രാമുകൾ പരിരക്ഷിക്കുന്നതിന് പോലും ജോലി ആവശ്യമാണ്. എന്നാൽ ഇപ്പോൾ MacOS-നുള്ള പുതിയ അക്രോണിസ് ഉൽപ്പന്നങ്ങൾക്ക് സിസ്റ്റത്തിൽ നിന്ന് അൺലോഡുചെയ്യുന്നതിനെതിരെ അധിക പരിരക്ഷ ലഭിക്കും.

അവലംബം: www.habr.com

MacOS-ൽ പ്രോസസ്സുകളും കേർണൽ എക്സ്റ്റൻഷനുകളും എങ്ങനെ സംരക്ഷിക്കാം