🥇 macOS मध्ये प्रक्रिया आणि कर्नल विस्तारांचे संरक्षण कसे करावे

हॅलो, हॅब्र! आज मी macOS मधील आक्रमणकर्त्यांच्या हल्ल्यांपासून प्रक्रियांचे संरक्षण कसे करू शकतो याबद्दल बोलू इच्छितो. उदाहरणार्थ, हे अँटीव्हायरस किंवा बॅकअप सिस्टमसाठी उपयुक्त आहे, विशेषत: macOS अंतर्गत प्रक्रिया "मारण्याचे" अनेक मार्ग आहेत. याबद्दल आणि कट अंतर्गत संरक्षण पद्धती वाचा.

प्रक्रिया "मारण्याचा" क्लासिक मार्ग

प्रक्रियेला "मारण्याचा" एक सुप्रसिद्ध मार्ग म्हणजे प्रक्रियेला SIGKILL सिग्नल पाठवणे. बॅशद्वारे तुम्ही मारण्यासाठी मानक "kill -SIGKILL PID" किंवा "pkill -9 NAME" कॉल करू शकता. "kill" कमांड UNIX च्या दिवसांपासून ओळखली जाते आणि ती केवळ macOS वरच नाही तर इतर UNIX सारख्या प्रणालींवर देखील उपलब्ध आहे.

UNIX सारख्या सिस्टीम प्रमाणे, macOS तुम्हाला दोन वगळता कोणत्याही प्रक्रियेसाठी सिग्नल रोखण्याची परवानगी देतो - SIGKILL आणि SIGSTOP. हा लेख प्रामुख्याने SIGKILL सिग्नलवर एक सिग्नल म्हणून लक्ष केंद्रित करेल ज्यामुळे प्रक्रिया मारली जाईल.

macOS तपशील

macOS वर, XNU कर्नलमधील किल सिस्टम कॉल psignal(SIGKILL,...) फंक्शनला कॉल करते. psignal फंक्शनद्वारे युजरस्पेसमधील इतर वापरकर्ता क्रियांना काय म्हटले जाऊ शकते ते पाहण्याचा प्रयत्न करूया. कर्नलच्या अंतर्गत यंत्रणेतील psignal फंक्शनचे कॉल काढून टाकू (जरी ते क्षुल्लक नसले तरी, आम्ही त्यांना दुसर्‍या लेखासाठी सोडू 🙂 - स्वाक्षरी पडताळणी, मेमरी त्रुटी, बाहेर पडणे/समाप्त करणे, फाइल संरक्षण उल्लंघन इ. .

चला फंक्शन आणि संबंधित सिस्टम कॉलसह पुनरावलोकन सुरू करूया terminate_with_payload. हे पाहिले जाऊ शकते की क्लासिक किल कॉल व्यतिरिक्त, एक पर्यायी दृष्टीकोन आहे जो 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 पर्यंत लॉन्चctl च्या जुन्या आवृत्तीसाठी आहेत, कोड उदाहरणे स्पष्टीकरणासाठी प्रदान केली आहेत. मॉडर्न लॉन्चक्टल 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 सह केवळ psignal नाही तर SIGKILL देखील पाठवू शकते.

अप्रत्यक्ष किल - संसाधन मर्यादा

आणखी एक मनोरंजक केस दुसर्या सिस्टम कॉलमध्ये पाहिले जाऊ शकते प्रक्रिया_पॉलिसी. या सिस्टीम कॉलचा सामान्य वापर म्हणजे ऍप्लिकेशन संसाधने मर्यादित करणे, जसे की इंडेक्सरसाठी CPU वेळ आणि मेमरी कोटा मर्यादित करणे जेणेकरुन फाइल कॅशिंग क्रियाकलापांद्वारे सिस्टम लक्षणीयरीत्या कमी होणार नाही. जर एखादा अनुप्रयोग त्याच्या संसाधन मर्यादेपर्यंत पोहोचला असेल, जसे की 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 प्रदान करते. एंडपॉईंट सिक्युरिटी 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 अधिकृतपणे समर्थित नाही.

कर्नल विस्तार संरक्षण

सिस्टममधील प्रक्रियांचे संरक्षण करण्याव्यतिरिक्त, कर्नल विस्तार स्वतः (केक्स्ट) संरक्षित करणे देखील आवश्यक आहे. 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);
}

लोड करताना IOUserClient द्वारे IsUnloadAllowed ध्वज सेट केला जाऊ शकतो. जेव्हा डाउनलोड मर्यादा असते, तेव्हा केक्सटनलोड कमांड खालील आउटपुट देईल:

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 प्रकरणे असू शकतात.

अंतिम स्थिती गाठली गेली आहे - मार्ग संरक्षित आहे, आम्ही KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA आणि KAUTH_VNODE_DELETE_CHILD ऑपरेशन्स मर्यादित करतो
अंतिम स्थिती गाठली गेली नाही, परंतु मार्ग “समाप्त” झाला (शून्य टर्मिनेटर पोहोचला) - पथ पालक आहे, तो KAUTH_VNODE_DELETE मर्यादित करणे आवश्यक आहे. लक्षात घ्या की vnode हे फोल्डर असल्यास, तुम्हाला शेवटी '/' जोडणे आवश्यक आहे, अन्यथा ते "/foor/bar/t" फाइलवर मर्यादित करू शकते, जे चुकीचे आहे.
अंतिम स्थिती गाठली नाही, मार्ग संपला नाही. कोणताही उपसर्ग याशी जुळत नाही, आम्ही निर्बंध आणत नाही.

निष्कर्ष

वापरकर्त्याच्या आणि त्याच्या डेटाच्या सुरक्षिततेची पातळी वाढवणे हे विकसित केलेल्या सुरक्षा उपायांचे उद्दिष्ट आहे. एकीकडे, हे लक्ष्य Acronis सॉफ्टवेअर उत्पादनाच्या विकासाद्वारे साध्य केले जाते, जे त्या असुरक्षा बंद करते जेथे ऑपरेटिंग सिस्टम स्वतः "कमकुवत" आहे. दुसरीकडे, OS च्या बाजूने सुधारता येऊ शकणार्‍या सुरक्षितता पैलूंना बळकट करण्याकडे आपण दुर्लक्ष करू नये, विशेषत: अशा भेद्यता बंद केल्याने उत्पादन म्हणून आपली स्वतःची स्थिरता वाढते. ऍपल उत्पादन सुरक्षा टीमला भेद्यतेची तक्रार करण्यात आली होती आणि ती macOS 10.14.5 (https://support.apple.com/en-gb/HT210119) मध्ये निश्चित केली गेली आहे.

जर तुमची उपयुक्तता अधिकृतपणे कर्नलमध्ये स्थापित केली गेली असेल तरच हे सर्व केले जाऊ शकते. म्हणजेच, बाह्य आणि अवांछित सॉफ्टवेअरसाठी अशा कोणत्याही त्रुटी नाहीत. तथापि, तुम्ही बघू शकता, अँटीव्हायरस आणि बॅकअप सिस्टम सारख्या कायदेशीर प्रोग्रामचे संरक्षण करण्यासाठी देखील कार्य आवश्यक आहे. परंतु आता macOS साठी नवीन Acronis उत्पादनांना सिस्टममधून अनलोडिंगपासून अतिरिक्त संरक्षण असेल.

स्त्रोत: www.habr.com

MacOS वर प्रक्रिया आणि कर्नल विस्तारांचे संरक्षण कसे करावे