როგორ დავიცვათ პროცესები და ბირთვის გაფართოებები macOS-ზე

გამარჯობა, ჰაბრ! დღეს მსურს ვისაუბრო იმაზე, თუ როგორ შეგიძლიათ დაიცვათ პროცესები macOS-ში თავდამსხმელებისგან თავდასხმებისგან. მაგალითად, ეს სასარგებლოა ანტივირუსული ან სარეზერვო სისტემისთვის, მით უმეტეს, რომ macOS-ის პირობებში პროცესის „მოკვლის“ რამდენიმე გზა არსებობს. წაიკითხეთ ამის შესახებ და დაცვის მეთოდები ჭრის ქვეშ.

პროცესის "მოკვლის" კლასიკური გზა

პროცესის „მოკვლის“ ცნობილი გზა არის პროცესზე SIGKILL სიგნალის გაგზავნა. ბაშის საშუალებით შეგიძლიათ მოკვლას უწოდოთ სტანდარტული "kill -SIGKILL PID" ან "pkill -9 NAME". "მკვლელობის" ბრძანება ცნობილია UNIX-ის დროიდან და ხელმისაწვდომია არა მხოლოდ macOS-ზე, არამედ UNIX-ის მსგავს სხვა სისტემებზეც.

ისევე, როგორც UNIX-ის მსგავს სისტემებში, macOS საშუალებას გაძლევთ ჩაჭრათ პროცესის ნებისმიერი სიგნალი, გარდა ორისა - SIGKILL და SIGSTOP. ეს სტატია პირველ რიგში ყურადღებას გაამახვილებს SIGKILL სიგნალზე, როგორც სიგნალზე, რომელიც იწვევს პროცესის მოკვლას.

macOS-ის სპეციფიკა

macOS-ზე მოკვლის სისტემის ზარი XNU ბირთვში იძახებს psignal(SIGKILL,...) ფუნქციას. შევეცადოთ ვნახოთ, რა სხვა მომხმარებლის ქმედებებს შეიძლება ეწოდოს მომხმარებლის სივრცეში psignal ფუნქცია. მოდი გამოვრიცხოთ პსიგნალის ფუნქციის გამოძახებები ბირთვის შიდა მექანიზმებში (თუმცა ისინი შეიძლება იყოს არა ტრივიალური, ჩვენ მათ სხვა სტატიისთვის დავტოვებთ 🙂 - ხელმოწერის გადამოწმება, მეხსიერების შეცდომები, გასვლა/დასრულება, ფაილების დაცვის დარღვევა და ა.შ. .

დავიწყოთ მიმოხილვა ფუნქციით და შესაბამისი სისტემური ზარით terminate_with_payload. ჩანს, რომ გარდა კლასიკური მოკვლის ზარისა, არსებობს ალტერნატიული მიდგომა, რომელიც სპეციფიკურია 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);
	}
...
}

გაუშვა

ამოქმედდა დემონების შექმნის სტანდარტული გზა სისტემის გაშვებისას და მათი სიცოცხლის კონტროლი. გთხოვთ, გაითვალისწინოთ, რომ წყაროები არის launchctl-ის ძველი ვერსიისთვის macOS 10.10-მდე, კოდის მაგალითები მოწოდებულია საილუსტრაციო მიზნებისთვის. თანამედროვე launchctl აგზავნის გაშვებულ სიგნალებს XPC-ით, მასში გადატანილია 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-ს, მიუხედავად მისი სახელისა, შეუძლია გაგზავნოს არა მხოლოდ psignal SIGTERM-ით, არამედ SIGKILL.

არაპირდაპირი მოკვლა - რესურსების ლიმიტი

უფრო საინტერესო შემთხვევა შეიძლება ნახოთ სხვა სისტემურ ზარში პროცესი_პოლიტიკა. ამ სისტემური გამოძახების საერთო გამოყენებაა აპლიკაციის რესურსების შეზღუდვა, მაგალითად, ინდექსატორისთვის CPU დროისა და მეხსიერების კვოტების შეზღუდვა ისე, რომ სისტემა მნიშვნელოვნად არ შენელდეს ფაილების ქეშირების აქტივობებით. თუ აპლიკაციამ მიაღწია რესურსის ლიმიტს, როგორც ჩანს proc_apply_resource_actions ფუნქციიდან, პროცესს ეგზავნება SIGKILL სიგნალი.

მიუხედავად იმისა, რომ ამ სისტემურ ზარს შეუძლია პოტენციურად გაანადგუროს პროცესი, სისტემამ სათანადოდ ვერ შეამოწმა სისტემური ზარის გამოძახების პროცესის უფლებები. რეალურად ამოწმებს არსებობდა, მაგრამ საკმარისია გამოიყენოთ ალტერნატიული დროშა PROC_POLICY_ACTION_SET ამ მდგომარეობის გვერდის ავლით.

აქედან გამომდინარე, თუ თქვენ „შეზღუდავთ“ აპლიკაციის CPU-ს გამოყენების კვოტას (მაგალითად, მხოლოდ 1 ns-ის გაშვების ნებას აძლევთ), მაშინ შეგიძლიათ მოკლათ ნებისმიერი პროცესი სისტემაში. ამრიგად, მავნე პროგრამას შეუძლია მოკლას სისტემაში არსებული ნებისმიერი პროცესი, მათ შორის ანტივირუსული პროცესი. ასევე საინტერესოა ეფექტი, რომელიც ჩნდება პროცესის მოკვლისას pid 1-ით (გაშვება) - ბირთვის პანიკა 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-ს პროცესებთან მუშაობისთვის. Endpoint Security API საშუალებას აძლევს კლიენტებს დაუშვან მრავალი მოთხოვნა სხვა პროცესებზე. ამრიგად, თქვენ შეგიძლიათ დაბლოკოთ ნებისმიერი სიგნალი პროცესებზე, მათ შორის SIGKILL სიგნალის ჩათვლით, ზემოთ აღნიშნული API-ს გამოყენებით.

#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) დაცვა. macOS უზრუნველყოფს დეველოპერებს ჩარჩოს, რათა ადვილად განავითარონ IOKit მოწყობილობის დრაივერები. მოწყობილობებთან მუშაობის ინსტრუმენტების მიწოდების გარდა, IOKit უზრუნველყოფს დრაივერების დაწყობის მეთოდებს C++ კლასების ინსტანციების გამოყენებით. მომხმარებელთა სივრცეში აპლიკაციას შეეძლება კლასის რეგისტრირებული მაგალითის „მოძებნა“ ბირთვისა და მომხმარებლის სივრცის ურთიერთობის დასამყარებლად.

სისტემაში კლასის შემთხვევების რაოდენობის დასადგენად, არსებობს ioclasscount პროგრამა.

my_kext_ioservice = 1
my_kext_iouserclient = 1

ნებისმიერი ბირთვის გაფართოება, რომელსაც სურს დარეგისტრირდეს დრაივერების დასტაში, უნდა გამოაცხადოს კლასი, რომელიც მემკვიდრეობით იღებს IOService-ს, მაგალითად my_kext_ioservice ამ შემთხვევაში. მომხმარებლის აპლიკაციების დაკავშირება იწვევს კლასის ახალი ინსტანციის შექმნას, რომელიც მემკვიდრეობით იღებს IOUserClient-ს, მაგალითში my_kext_iouserclient.

როდესაც ცდილობთ დრაივერის სისტემიდან გადმოტვირთვას (kextunload ბრძანება), გამოიძახება ვირტუალური ფუნქცია "bool terminate(IOOptionBits options)". საკმარისია გამოძახებაზე false დააბრუნოთ, რათა შეწყდეს განტვირთვის მცდელობისას, რათა გამორთოთ kextunload.

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 userspace ფუნქციის „IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t description);“ გამოყენებით. თქვენ შეგიძლიათ დააბრუნოთ false ბრძანების "terminate" გამოძახებისას, სანამ მომხმარებლის სივრცის აპლიკაცია "მოკვდება", ანუ "clientDied" ფუნქცია არ გამოიძახება.

ფაილის დაცვა

ფაილების დასაცავად საკმარისია გამოიყენოთ 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 არის საქაღალდე, თქვენ უნდა დაამატოთ '/' ბოლოს, წინააღმდეგ შემთხვევაში შეიძლება შეზღუდოს ის ფაილით "/foor/bar/t", რაც არასწორია.
3. საბოლოო მდგომარეობა არ იყო მიღწეული, გზა არ დასრულებულა. არცერთი პრეფიქსი არ ემთხვევა ამას, ჩვენ არ ვაწესებთ შეზღუდვებს.

დასკვნა

შემუშავებული უსაფრთხოების გადაწყვეტილებების მიზანია მომხმარებლის და მისი მონაცემების უსაფრთხოების დონის ამაღლება. ერთის მხრივ, ამ მიზანს მიიღწევა Acronis პროგრამული პროდუქტის შემუშავებით, რომელიც ხურავს იმ დაუცველობას, სადაც თავად ოპერაციული სისტემა „სუსტია“. მეორეს მხრივ, ჩვენ არ უნდა უგულებელვყოთ უსაფრთხოების იმ ასპექტების გაძლიერება, რომლებიც შეიძლება გაუმჯობესდეს OS-ის მხარეს, მით უმეტეს, რომ ასეთი დაუცველობის დახურვა ზრდის ჩვენს სტაბილურობას, როგორც პროდუქტის. დაუცველობა ეცნობა Apple-ის პროდუქტის უსაფრთხოების გუნდს და დაფიქსირდა macOS 10.14.5-ში (https://support.apple.com/en-gb/HT210119).

ეს ყველაფერი შეიძლება გაკეთდეს მხოლოდ იმ შემთხვევაში, თუ თქვენი პროგრამა ოფიციალურად დაინსტალირებულია ბირთვში. ანუ, არ არსებობს ასეთი ხარვეზები გარე და არასასურველი პროგრამული უზრუნველყოფისთვის. თუმცა, როგორც ხედავთ, ლეგიტიმური პროგრამების დაცვაც კი, როგორიცაა ანტივირუსი და სარეზერვო სისტემები, მოითხოვს მუშაობას. მაგრამ ახლა MacOS-ისთვის Acronis-ის ახალ პროდუქტებს ექნებათ დამატებითი დაცვა სისტემიდან გადმოტვირთვისგან.

წყარო: www.habr.com