புரோஹோஸ்டர் > Блог > நிர்வாகம் > MacOS இல் செயல்முறைகள் மற்றும் கர்னல் நீட்டிப்புகளை எவ்வாறு பாதுகாப்பது

MacOS இல் செயல்முறைகள் மற்றும் கர்னல் நீட்டிப்புகளை எவ்வாறு பாதுகாப்பது

வணக்கம், ஹப்ர்! MacOS இல் தாக்குபவர்களின் தாக்குதல்களிலிருந்து செயல்முறைகளை எவ்வாறு பாதுகாப்பது என்பது பற்றி இன்று நான் பேச விரும்புகிறேன். எடுத்துக்காட்டாக, வைரஸ் தடுப்பு அல்லது காப்புப்பிரதி அமைப்புக்கு இது பயனுள்ளதாக இருக்கும், குறிப்பாக MacOS இன் கீழ் ஒரு செயல்முறையை "கொல்ல" பல வழிகள் உள்ளன. வெட்டு கீழ் இது மற்றும் பாதுகாப்பு முறைகள் பற்றி படிக்கவும்.

MacOS இல் செயல்முறைகள் மற்றும் கர்னல் நீட்டிப்புகளை எவ்வாறு பாதுகாப்பது

ஒரு செயல்முறையை "கொல்ல" உன்னதமான வழி

ஒரு செயல்முறையை "கொல்ல" ஒரு நன்கு அறியப்பட்ட வழி, செயல்முறைக்கு SIGKILL சமிக்ஞையை அனுப்புவதாகும். பாஷ் மூலம் நீங்கள் "கில் -SIGKILL PID" அல்லது "pkill -9 NAME" ஐ கொல்ல அழைக்கலாம். "கில்" கட்டளை UNIX காலத்திலிருந்தே அறியப்படுகிறது மற்றும் இது macOS இல் மட்டுமல்ல, UNIX போன்ற பிற அமைப்புகளிலும் கிடைக்கிறது.

UNIX போன்ற அமைப்புகளைப் போலவே, SIGKILL மற்றும் SIGSTOP ஆகிய இரண்டைத் தவிர ஒரு செயல்முறைக்கான எந்த சமிக்ஞைகளையும் இடைமறிக்க macOS உங்களை அனுமதிக்கிறது. இந்தக் கட்டுரையானது முதன்மையாக 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);
	}
...
}

தொடங்கப்பட்டது

சிஸ்டம் ஸ்டார்ட்அப்பில் டெமான்களை உருவாக்கி அவற்றின் வாழ்நாளைக் கட்டுப்படுத்துவதற்கான நிலையான வழி தொடங்கப்பட்டது. 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 சிக்னலைச் செயலாக்க முயற்சிக்கும்போது கர்னல் பீதி :)

MacOS இல் செயல்முறைகள் மற்றும் கர்னல் நீட்டிப்புகளை எவ்வாறு பாதுகாப்பது

சிக்கலை எவ்வாறு தீர்ப்பது?

ஒரு செயல்முறை கொல்லப்படுவதைத் தடுக்க மிகவும் நேரடியான வழி, கணினி அழைப்பு அட்டவணையில் செயல்பாட்டு சுட்டிக்காட்டியை மாற்றுவதாகும். துரதிர்ஷ்டவசமாக, இந்த முறை பல காரணங்களுக்காக அற்பமானது அல்ல.

முதலாவதாக, 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;
}

இதேபோல், ஒரு MAC கொள்கையை கர்னலில் பதிவு செய்யலாம், இது ஒரு சமிக்ஞை பாதுகாப்பு முறையை வழங்குகிறது (policy proc_check_signal), ஆனால் API அதிகாரப்பூர்வமாக ஆதரிக்கப்படவில்லை.

கர்னல் நீட்டிப்பு பாதுகாப்பு

கணினியில் செயல்முறைகளைப் பாதுகாப்பதோடு, கர்னல் நீட்டிப்பைப் பாதுகாப்பதும் (kext) அவசியம். IOKit சாதன இயக்கிகளை எளிதாக உருவாக்க மேகோஸ் டெவலப்பர்களுக்கு ஒரு கட்டமைப்பை வழங்குகிறது. சாதனங்களுடன் வேலை செய்வதற்கான கருவிகளை வழங்குவதோடு, 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ஐ கட்டுப்படுத்துவது அவசியம்.

MacOS இல் செயல்முறைகள் மற்றும் கர்னல் நீட்டிப்புகளை எவ்வாறு பாதுகாப்பது

முன்னொட்டுகளின் எண்ணிக்கை அதிகரிக்கும் போது இந்த அணுகுமுறையின் தீமை குறைந்த செயல்திறன் இருக்கலாம். ஒப்பீடு O(முன்னொட்டு* நீளம்) க்கு சமமாக இல்லை என்பதை உறுதிப்படுத்த, முன்னொட்டு என்பது முன்னொட்டுகளின் எண்ணிக்கை, நீளம் என்பது சரத்தின் நீளம், நீங்கள் முன்னொட்டுகளால் கட்டமைக்கப்பட்ட வரையறுக்கப்பட்ட ஆட்டோமேட்டனை (DFA) பயன்படுத்தலாம்.

கொடுக்கப்பட்ட முன்னொட்டுகளின் தொகுப்பிற்கு டிஎஃப்ஏவை உருவாக்குவதற்கான முறையைப் பார்ப்போம். ஒவ்வொரு முன்னொட்டின் தொடக்கத்திலும் கர்சர்களை துவக்குகிறோம். அனைத்து கர்சர்களும் ஒரே எழுத்தை சுட்டிக்காட்டினால், ஒவ்வொரு கர்சரையும் ஒரு எழுத்தால் அதிகரிக்கவும், அதே வரியின் நீளம் ஒன்று அதிகமாக இருப்பதை நினைவில் கொள்ளவும். வெவ்வேறு குறியீடுகளுடன் இரண்டு கர்சர்கள் இருந்தால், அவை சுட்டிக்காட்டும் குறியீட்டின் படி கர்சர்களை குழுக்களாகப் பிரித்து, ஒவ்வொரு குழுவிற்கும் அல்காரிதத்தை மீண்டும் செய்யவும்.

முதல் வழக்கில் (கர்சர்களின் கீழ் உள்ள அனைத்து எழுத்துகளும் ஒரே மாதிரியானவை), ஒரே வரியில் ஒரே ஒரு மாற்றத்தைக் கொண்ட டிஎஃப்ஏ நிலையைப் பெறுகிறோம். இரண்டாவது வழக்கில், செயல்பாட்டை மீண்டும் மீண்டும் அழைப்பதன் மூலம் பெறப்பட்ட அடுத்தடுத்த நிலைகளுக்கு அளவு 256 (எழுத்துகளின் எண்ணிக்கை மற்றும் அதிகபட்ச எண்ணிக்கையிலான குழுக்களின்) மாற்றங்களின் அட்டவணையைப் பெறுகிறோம்.

ஒரு உதாரணத்தைப் பார்ப்போம். முன்னொட்டுகளின் தொகுப்பிற்கு (“/foo/bar/tmp/”, “/var/db/foo/”, “/foo/bar/aba/”, “foo/bar/aac/”) நீங்கள் பின்வருவனவற்றைப் பெறலாம் டிஎஃப்ஏ. படம் மற்ற மாநிலங்களுக்கு செல்லும் மாற்றங்களை மட்டுமே காட்டுகிறது; மற்ற மாற்றங்கள் இறுதியானதாக இருக்காது.

MacOS இல் செயல்முறைகள் மற்றும் கர்னல் நீட்டிப்புகளை எவ்வாறு பாதுகாப்பது

DKA மாநிலங்கள் வழியாக செல்லும் போது, ​​3 வழக்குகள் இருக்கலாம்.

  1. இறுதி நிலையை அடைந்து விட்டது - பாதை பாதுகாக்கப்பட்டுள்ளது, KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA மற்றும் KAUTH_VNODE_DELETE_CHILD செயல்பாடுகளை வரம்பிடுகிறோம்
  2. இறுதி நிலையை அடையவில்லை, ஆனால் பாதை “முடிந்தது” (பூஜ்ய முனையத்தை அடைந்தது) - பாதை ஒரு பெற்றோர், KAUTH_VNODE_DELETE ஐ வரம்பிட வேண்டியது அவசியம். vnode ஒரு கோப்புறையாக இருந்தால், நீங்கள் இறுதியில் '/' ஐச் சேர்க்க வேண்டும், இல்லையெனில் அது "/for/bar/t" கோப்புக்கு வரம்பிடலாம், இது தவறானது.
  3. இறுதி நிலையை அடையவில்லை, பாதை முடிவடையவில்லை. முன்னொட்டுகள் எதுவும் இதனுடன் பொருந்தவில்லை, நாங்கள் கட்டுப்பாடுகளை அறிமுகப்படுத்தவில்லை.

முடிவுக்கு

உருவாக்கப்படும் பாதுகாப்பு தீர்வுகளின் குறிக்கோள், பயனர் மற்றும் அவரது தரவின் பாதுகாப்பின் அளவை அதிகரிப்பதாகும். ஒருபுறம், அக்ரோனிஸ் மென்பொருள் தயாரிப்பின் வளர்ச்சியால் இந்த இலக்கு அடையப்படுகிறது, இது இயக்க முறைமையே "பலவீனமாக" இருக்கும் பாதிப்புகளை மூடுகிறது. மறுபுறம், OS பக்கத்தில் மேம்படுத்தக்கூடிய பாதுகாப்பு அம்சங்களை வலுப்படுத்துவதை நாம் புறக்கணிக்கக்கூடாது, குறிப்பாக இதுபோன்ற பாதிப்புகளை மூடுவது ஒரு தயாரிப்பாக நமது சொந்த நிலைத்தன்மையை அதிகரிக்கிறது. இந்த பாதிப்பு ஆப்பிள் தயாரிப்பு பாதுகாப்பு குழுவிற்கு தெரிவிக்கப்பட்டது மற்றும் macOS 10.14.5 (https://support.apple.com/en-gb/HT210119) இல் சரி செய்யப்பட்டது.

MacOS இல் செயல்முறைகள் மற்றும் கர்னல் நீட்டிப்புகளை எவ்வாறு பாதுகாப்பது

உங்கள் பயன்பாடு அதிகாரப்பூர்வமாக கர்னலில் நிறுவப்பட்டிருந்தால் மட்டுமே இவை அனைத்தையும் செய்ய முடியும். அதாவது, வெளிப்புற மற்றும் தேவையற்ற மென்பொருளுக்கு அத்தகைய ஓட்டைகள் இல்லை. இருப்பினும், நீங்கள் பார்க்கிறபடி, வைரஸ் தடுப்பு மற்றும் காப்பு அமைப்புகள் போன்ற முறையான நிரல்களைப் பாதுகாப்பதற்கு கூட வேலை தேவைப்படுகிறது. ஆனால் இப்போது மேகோஸிற்கான புதிய அக்ரோனிஸ் தயாரிப்புகள் கணினியிலிருந்து இறக்குவதற்கு எதிராக கூடுதல் பாதுகாப்பைக் கொண்டிருக்கும்.

ஆதாரம்: www.habr.com

கருத்தைச் சேர்