{"id":78514,"date":"2020-04-20T01:42:32","date_gmt":"2020-04-19T23:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos"},"modified":"2020-04-20T01:42:32","modified_gmt":"2020-04-19T23:42:32","slug":"kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos","title":{"rendered":"Come proteggere i processi e le estensioni del kernel in macOS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr! Oggi vorrei parlare di come proteggere i processi da attacchi malevoli su macOS. Questo \u00e8 utile ad esempio per gli antivirus o i sistemi di backup, specialmente considerando che su macOS ci sono diversi modi per 'terminare' un processo. Leggi di pi\u00f9 sui metodi di protezione qui sotto.<\/p>\n

\"Come<\/a><\/noindex>
\n<\/a><\/noindex><\/p>\n

Metodo classico per 'terminare' un processo<\/h3>\n

\nUn metodo ben noto per 'terminare' un processo \u00e8 inviare un segnale SIGKILL al processo. Tramite bash, puoi utilizzare i comandi standard 'kill -SIGKILL PID' o 'pkill -9 NAME' per terminare. Il comando 'kill' \u00e8 conosciuto fin dai tempi di UNIX ed \u00e8 disponibile non solo su macOS, ma anche su altri sistemi UNIX-like.<\/p>\n

Cos\u00ec come nei sistemi UNIX-like, macOS consente di intercettare qualsiasi segnale per un processo, tranne due: SIGKILL e SIGSTOP. In questo articolo si parler\u00e0 principalmente del segnale SIGKILL, che provoca la terminazione del processo.<\/p>\n

Specificit\u00e0 di macOS
\n<\/h3>\n

\nNella macOS, la chiamata di sistema kill nel kernel XNU invoca la funzione psignal(SIGKILL,…). Vediamo quali altre azioni dell'utente nello userspace possono attivare la funzione psignal. Escludiamo le chiamate alla funzione psignal nei meccanismi interni del kernel (anche se possono essere complesse, ma le riserveremo per un altro articolo \ud83d\ude42 \u2014 controllo della firma, errori di memoria, gestione di exit\/terminate, violazione della protezione dei file, ecc.). <\/p>\n

Let's start the review with the function and the corresponding system call terminate_with_payload<\/a><\/noindex>. It is evident that besides the classic kill call, there is an alternative approach that is specific to the macOS operating system and does not occur in BSD. The principles of operation for both system calls are also similar. They directly invoke the kernel function psignal. We also note that before killing a process, a check is made to see if the process can send a signal to another process; the system does not allow any application to terminate system processes, for example.<\/p>\n

static int\nterminate_with_payload_internal(struct proc *cur_proc, int target_pid, uint32_t reason_namespace,\n\t\t\t\tuint64_t reason_code, user_addr_t payload, uint32_t payload_size,\n\t\t\t\tuser_addr_t reason_string, uint64_t reason_flags)\n{\n...\n\ttarget_proc = proc_find(target_pid);\n...\n\tif (!cansignal(cur_proc, cur_cred, target_proc, SIGKILL)) {\n\t\tproc_rele(target_proc);\n\t\treturn EPERM;\n\t}\n...\n\tif (target_pid == cur_proc->p_pid) {\n\t\t\/*\n\t\t * psignal_thread_with_reason() sospende un SIGKILL sul thread specificato o\n\t\t * restituisce se il thread e\/o il task stanno gi\u00e0 terminando. In entrambi i casi, il\n\t\t * thread corrente non torner\u00e0 nello spazio degli utenti.\n\t\t *\/\n\t\tpsignal_thread_with_reason(target_proc, current_thread(), SIGKILL, signal_reason);\n\t} else {\n\t\tpsignal_with_reason(target_proc, SIGKILL, signal_reason);\n\t}\n...\n}\n<\/code><\/pre>\n
<\/p>\n
launchd<\/h3>\n
\nIl modo standard per creare demoni all'avvio del sistema e controllarne il ciclo di vita \u00e8 launchd. Vorrei sottolineare che i sorgenti forniti sono per una vecchia versione di launchctl precedente a macOS 10.10, e gli esempi di codice sono forniti a scopo illustrativo. L'attuale launchctl invia segnali a launchd tramite XPC, mentre la logica di launchctl \u00e8 stata trasferita in esso.<\/p>\n
Esaminiamo come avviene esattamente l'arresto delle applicazioni. Prima di inviare il segnale SIGTERM, l'applicazione viene tentata di essere arrestata tramite la chiamata di sistema \u201cproc_terminate\u201d.<\/p>\n
...\n\terror = proc_terminate(j->p, &sig);\n\tif (error) {\n\t\tjob_log(j, LOG_ERR | LOG_CONSOLE, "Impossibile terminare il lavoro: %d: %s", error, strerror(error));\n\t\tjob_log(j, LOG_NOTICE | LOG_CONSOLE, "Utilizzo dell'opzione di fallback per terminare il lavoro...");\n\t\terror = kill2(j->p, SIGTERM);\n\t\tif (error) {\n\t\t\tjob_log(j, LOG_ERR, "Impossibile segnalare il lavoro: %d: %s", error, strerror(error));\n\t\t} \n...\n<\/code><\/pre>\n
\nSotto il cofano, proc_terminate, nonostante il suo nome, pu\u00f2 inviare non solo psignal con SIGTERM, ma anche SIGKILL.<\/p>\n
Uccisione indiretta - limitazione delle risorse<\/h3>\n
\nUn caso pi\u00f9 interessante pu\u00f2 essere visto in un'altra chiamata di sistema process_policy<\/a><\/noindex>. L'uso standard di questa chiamata di sistema \u00e8 la limitazione delle risorse delle applicazioni, ad esempio per un indicizzatore limitare il tempo di CPU e la memoria, affinch\u00e9 il sistema non venga rallentato in modo significativo dalle azioni di caching dei file. Se l'applicazione ha raggiunto il limite delle risorse, come si pu\u00f2 vedere dalla funzione proc_apply_resource_actions, al processo viene inviato il segnale SIGKILL.<\/p>\n
Nonostante questa chiamata di sistema possa potenzialmente produrre l'uccisione di un processo, il sistema non ha controllato adeguatamente i diritti del processo che effettua la chiamata di sistema. In realt\u00e0, il controllo esisteva<\/a><\/noindex>, ma \u00e8 sufficiente utilizzare il flag alternativo PROC_POLICY_ACTION_SET per aggirare questa condizione.<\/p>\n
Di conseguenza, se si \"limita\" la quota di utilizzo della CPU da parte di un'applicazione (ad esempio, consentendo l'esecuzione di solo 1 ns), allora si pu\u00f2 terminare qualsiasi processo nel sistema. In questo modo, un malware pu\u00f2 terminare qualsiasi processo nel sistema, incluso il processo antivirus. Interessante \u00e8 anche l'effetto che si ottiene terminando il processo con pid 1 (launchctl) \u2014 kernel panic quando si tenta di gestire il segnale SIGKILL \ud83d\ude42<\/p>\n
\"Come
\n<\/p>\n
Come risolvere il problema?<\/h3>\n
\nIl modo pi\u00f9 diretto per impedire l'uccisione di un processo \u00e8 sostituire il puntatore alla funzione nella tabella delle chiamate di sistema. Sfortunatamente, questo metodo non \u00e8 banale per molte ragioni.<\/p>\n
In primo luogo, il simbolo che corrisponde alla posizione di sysent in memoria non \u00e8 solo un simbolo privato del kernel XNU, ma non pu\u00f2 essere trovato nei simboli del kernel. Dovremo utilizzare metodi euristici di ricerca, come la disassemblaggio dinamico della funzione e la ricerca del puntatore in essa.<\/p>\n
In secondo luogo, la struttura delle voci nella tabella dipende dai flag con cui \u00e8 stato compilato il kernel. Se \u00e8 stato dichiarato il flag CONFIG_REQUIRES_U32_MUNGING, la dimensione della struttura verr\u00e0 modificata: verr\u00e0 aggiunto un campo aggiuntivo. sy_arg_munge32<\/a><\/noindex>. \u00c8 necessario effettuare un'ulteriore verifica su quale flag \u00e8 stato utilizzato per compilare il kernel, ad esempio confrontando i puntatori delle funzioni con quelli noti.<\/p>\n
struct sysent {         \/* tabella delle chiamate di sistema *\/\n        sy_call_t       *sy_call;       \/* funzione di implementazione *\/\n#if CONFIG_REQUIRES_U32_MUNGING || (__arm__ && (__BIGGEST_ALIGNMENT__ > 4))\n        sy_munge_t      *sy_arg_munge32; \/* modificatore degli argomenti delle chiamate di sistema per processi a 32 bit *\/\n#endif\n        int32_t         sy_return_type; \/* tipi di ritorno delle chiamate di sistema *\/\n        int16_t         sy_narg;        \/* numero di argomenti *\/\n        uint16_t        sy_arg_bytes;   \/* Dimensione totale degli argomenti in byte per\n                                         * chiamate di sistema a 32 bit\n                                         *\/\n};\n<\/code><\/pre>\n
\nFortunatamente, nelle versioni moderne di macOS, Apple fornisce una nuova API per lavorare con i processi. L'API di Endpoint Security consente ai client di autorizzare molte richieste ad altri processi. In questo modo, \u00e8 possibile bloccare segnali a processi, incluso il segnale SIGKILL, utilizzando l'API sopracitata.<\/p>\n
#include <bsm\/libbsm.h>\n#include <EndpointSecurity\/EndpointSecurity.h>\n#include <unistd.h>\n\nint main(int argc, const char * argv[]) {\n    es_client_t* cli = nullptr;\n    {\n        auto res = es_new_client(&cli, ^(es_client_t * client, const es_message_t * message) {\n            switch (message->event_type) {\n                case ES_EVENT_TYPE_AUTH_SIGNAL:\n                {\n                    auto& msg = message->event.signal;\n                    auto target = msg.target;\n                    auto& token = target->audit_token;\n                    auto pid = audit_token_to_pid(token);\n                    printf("signal '%d' sent to pid '%d'n", msg.sig, pid);\n                    es_respond_auth_result(client, message, pid == getpid() ? ES_AUTH_RESULT_DENY : ES_AUTH_RESULT_ALLOW, false);\n                }\n                    break;\n                default:\n                    break;\n            }\n        });\n    }\n\n    {\n        es_event_type_t evs[] = { ES_EVENT_TYPE_AUTH_SIGNAL };\n        es_subscribe(cli, evs, sizeof(evs) \/ sizeof(*evs));\n    }\n\n    printf("%dn", getpid());\n    sleep(60); \/\/ could be replaced with other waiting primitive\n\n    es_unsubscribe_all(cli);\n    es_delete_client(cli);\n\n    return 0;\n}\n<\/code><\/pre>\n
\nAllo stesso modo, nel kernel \u00e8 possibile registrare una MAC Policy, che fornisce un metodo di protezione dai segnali (policy proc_check_signal), tuttavia l'API non \u00e8 ufficialmente supportata.<\/p>\n
Protezione dell'estensione del kernel<\/h3>\n
\nOltre a proteggere i processi nel sistema, \u00e8 essenziale proteggere anche l'estensione del kernel (kext). macOS offre agli sviluppatori un framework per facilitare lo sviluppo dei driver di dispositivo IOKit. Oltre a fornire strumenti per interagire con i dispositivi, IOKit offre metodi per la sovrapposizione dei driver (driver stacking) attraverso istanze di classi C++. Un'applicazione nel userspace sar\u00e0 in grado di \"trovare\" un'istanza di classe registrata per stabilire una connessione kernel-userspace.<\/p>\n
Per scoprire il numero di istanze di classi nel sistema esiste un'utilit\u00e0 chiamata ioclasscount.<\/p>\n
my_kext_ioservice = 1\nmy_kext_iouserclient = 1\n<\/code><\/pre>\n
\nQualsiasi estensione del kernel che desidera registrarsi nello stack dei driver deve dichiarare una classe ereditata da IOService, ad esempio, my_kext_ioservice in questo caso. La connessione di applicazioni utente provoca la creazione di una nuova istanza di classe, che \u00e8 ereditata da IOUserClient, nell'esempio my_kext_iouserclient.<\/p>\n
Quando si tenta di scaricare un driver dal sistema (comando kextunload), viene chiamata la funzione virtuale \"bool terminate(IOOptionBits options)\". \u00c8 sufficiente restituire false alla chiamata della funzione terminate durante il tentativo di scarico per vietare kextunload.<\/p>\n
bool Kext::terminate(IOOptionBits options)\n{\n\n  if (!IsUnloadAllowed)\n  {\n    \\\/\\\/ Il download non \u00e8 consentito, restituito false\n    return false;\n  }\n\n  return super::terminate(options);\n}\n\n<\/code><\/pre>\n
\nIl flag IsUnloadAllowed pu\u00f2 essere impostato da IOUserClient durante il caricamento. Con un vincolo sul caricamento, il comando kextunload restituir\u00e0 il seguente output:<\/p>\n
admin@admins-Mac drivermanager % sudo kextunload .\\\/test.kext\nPassword:\n(kernel) Impossibile rimuovere kext my.kext.test; i servizi non sono riusciti a terminare - 0xe00002c7.\nImpossibile scaricare my.kext.test - (iokit\\\/common) funzione non supportata.\n<\/code><\/pre>\n
\nUna protezione analoga deve essere attuata anche per IOUserClient. Le istanze delle classi possono essere scaricate tramite la funzione userspace IOKitLib \"IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t description);\". Si pu\u00f2 restituire false alla chiamata del comando \"terminate\" finch\u00e9 l'applicazione userspace non \"muore\", ossia fino a che non viene chiamata la funzione \"clientDied\".<\/p>\n
Protezione dei file<\/h3>\n
\nPer proteggere i file, \u00e8 sufficiente utilizzare il Kauth API, che consente di limitare l'accesso ai file. Apple fornisce agli sviluppatori notifiche su vari eventi nel contesto, e per noi sono rilevanti le operazioni KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA e KAUTH_VNODE_DELETE_CHILD. Limitare l'accesso ai file \u00e8 pi\u00f9 semplice utilizzando il percorso: usiamo l'API \u201cvn_getpath\u201d per ottenere il percorso del file e confrontiamo il prefisso del percorso. Si noti che, per ottimizzare la rinomina dei percorsi delle cartelle contenenti file, il sistema non autorizza l'accesso a ciascun file, ma solo alla cartella stessa che \u00e8 stata rinominata. \u00c8 necessario confrontare il percorso genitore e limitare KAUTH_VNODE_DELETE per esso.<\/p>\n
\"Come
\n
\nUno svantaggio di questo approccio pu\u00f2 essere la bassa performance con un aumento del numero di prefissi. Per evitare che il confronto sia O(prefix*length), dove prefix \u00e8 il numero di prefissi e length \u00e8 la lunghezza della stringa, si pu\u00f2 utilizzare un automa a stati finiti deterministico (DFA) costruito sui prefissi. <\/p>\n
Consideriamo un metodo per costruire un DFA per questo insieme di prefissi. Iniziamo le corsie all'inizio di ciascun prefisso. Se tutte le corsie puntano allo stesso simbolo, incrementiamo ciascuna corsia di un simbolo e ricordiamo che la lunghezza della stringa identica aumenta di uno. Se ci sono due corsie con simboli diversi, dividiamo le corsie in gruppi in base al simbolo su cui puntano e ripetiamo l'algoritmo per ogni gruppo.<\/p>\n
Nel primo caso (quando tutti i simboli sotto le corsie sono uguali), otteniamo uno stato del DFA che ha solo una transizione per la stringa identica. Nel secondo caso, otteniamo una tabella di transizioni di dimensioni 256 (numero di simboli e massimo numero di gruppi) per gli stati successivi, ottenuti mediante la chiamata ricorsiva della funzione.<\/p>\n
Prendiamo un esempio. Per l'insieme di prefissi (\u201c\/foo\/bar\/tmp\/\u201d, \u201c\/var\/db\/foo\/\u201d, \u201c\/foo\/bar\/aba\/\u201d, \u201cfoo\/bar\/aac\/\u201d) possiamo ottenere il seguente DFA. Nella figura sono indicate solo le transizioni che portano ad altri stati; le altre transizioni non saranno finali.<\/p>\n
\"Come
\n
\nDurante il passaggio attraverso gli stati del DFA possono verificarsi 3 casi.<\/p>\n
    \n
  1. \u00c8 stato raggiunto lo stato finale: il percorso \u00e8 protetto, limitando le operazioni KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA e KAUTH_VNODE_DELETE_CHILD.<\/li>\n
  2. Non \u00e8 stato raggiunto lo stato finale, ma il percorso \u00e8 \"terminato\" (\u00e8 stato raggiunto il terminatore zero): il percorso \u00e8 genitore e KAUTH_VNODE_DELETE deve essere limitato. Si noti che se il vnode \u00e8 una cartella, \u00e8 necessario aggiungere \u2018\/\u2019 alla fine; altrimenti, potrebbe essere limitato al file \"\/foor\/bar\/t\", il che \u00e8 errato.<\/li>\n
  3. Non \u00e8 stato raggiunto lo stato finale, il percorso non \u00e8 terminato. Nessuno dei prefissi corrisponde a questo, non introduciamo limitazioni.<\/li>\n<\/ol>\n
    <\/p>\n
    Conclusione<\/h3>\n
    \nL'obiettivo delle soluzioni di sicurezza in fase di sviluppo \u00e8 aumentare il livello di sicurezza dell'utente e dei suoi dati. Da un lato, questo obiettivo \u00e8 garantito dallo sviluppo del prodotto software Acronis, che chiude quelle vulnerabilit\u00e0 in cui il sistema operativo \u00e8 \"debole\". D'altro canto, non si dovrebbe trascurare il rafforzamento degli aspetti di sicurezza che possono essere migliorati a livello di OS, soprattutto considerando che la chiusura di tali vulnerabilit\u00e0 aumenta la nostra resilienza come prodotto. La vulnerabilit\u00e0 \u00e8 stata segnalata dal team di sicurezza dei prodotti Apple ed \u00e8 stata corretta in macOS 10.14.5 (https:\/\/support.apple.com\/en-gb\/HT210119).<\/p>\n
    \"Come
    \n
    \nTutto ci\u00f2 pu\u00f2 essere fatto solo se la vostra utility \u00e8 stata ufficialmente installata nel kernel. Questo significa che non ci sono scorciatoie per software esterni e indesiderati. Tuttavia, come potete vedere, anche per proteggere programmi legittimi come gli antivirus e i sistemi di backup bisogna lavorare. Ma ora i nuovi prodotti Acronis per macOS avranno una protezione aggiuntiva contro l'uscita dal sistema.
    \n
    Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u043d\u0435 \u0445\u043e\u0442\u0435\u043b\u043e\u0441\u044c \u0431\u044b \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b \u043e\u0442 \u043f\u043e\u0441\u044f\u0433\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u043e\u0432 \u0432 macOS. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u044d\u0442\u043e \u043f\u043e\u043b\u0435\u0437\u043d\u043e \u0434\u043b\u044f \u0430\u043d\u0442\u0438\u0432\u0438\u0440\u0443\u0441\u0430 \u0438\u043b\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0432 \u0441\u0432\u0435\u0442\u0435 \u0442\u043e\u0433\u043e \u0447\u0442\u043e \u043f\u043e\u0434 macOS \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 \u0441\u0440\u0430\u0437\u0443 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0441\u043f\u043e\u0441\u043e\u0431\u043e\u0432 \u201c\u0443\u0431\u0438\u0442\u044c\u201d \u043f\u0440\u043e\u0446\u0435\u0441\u0441. \u041e\u0431 \u044d\u0442\u043e\u043c \u0438 \u043e \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u0437\u0430\u0449\u0438\u0442\u044b \u0447\u0438\u0442\u0430\u0439\u0442\u0435 \u043f\u043e\u0434 \u043a\u0430\u0442\u043e\u043c. \u041a\u043b\u0430\u0441\u0441\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0441\u043f\u043e\u0441\u043e\u0431 \u201c\u0443\u0431\u0438\u0442\u044c\u201d \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0412\u0441\u0435\u043c \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u044b\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":78515,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-78514","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Come proteggere processi e estensioni del kernel in macOS | ProHoster","description":"Ciao, Habr! Oggi vorrei discutere di come proteggere i processi da attacchi di malintenzionati in macOS. Ad esempio, questo \u00e8 utile per antivirus o sistemi di backup, specialmente considerando che in macOS esistono diversi modi per \"terminare\" un processo. Leggi di pi\u00f9 sui metodi di protezione qui sotto. Il metodo classico per \"terminare\" un processo \u00e8 ben noto a tutti.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u0437\u0430\u0449\u0438\u0449\u0430\u0442\u044c \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b \u0438 \u0440\u0430\u0441\u0448\u0438\u0440\u0435\u043d\u0438\u044f \u044f\u0434\u0440\u0430 \u0432 macOS | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u043d\u0435 \u0445\u043e\u0442\u0435\u043b\u043e\u0441\u044c \u0431\u044b \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b \u043e\u0442 \u043f\u043e\u0441\u044f\u0433\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a\u043e\u0432 \u0432 macOS. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u044d\u0442\u043e \u043f\u043e\u043b\u0435\u0437\u043d\u043e \u0434\u043b\u044f \u0430\u043d\u0442\u0438\u0432\u0438\u0440\u0443\u0441\u0430 \u0438\u043b\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0432 \u0441\u0432\u0435\u0442\u0435 \u0442\u043e\u0433\u043e \u0447\u0442\u043e \u043f\u043e\u0434 macOS \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 \u0441\u0440\u0430\u0437\u0443 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0441\u043f\u043e\u0441\u043e\u0431\u043e\u0432 \u201c\u0443\u0431\u0438\u0442\u044c\u201d \u043f\u0440\u043e\u0446\u0435\u0441\u0441. \u041e\u0431 \u044d\u0442\u043e\u043c \u0438 \u043e \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u0437\u0430\u0449\u0438\u0442\u044b \u0447\u0438\u0442\u0430\u0439\u0442\u0435 \u043f\u043e\u0434 \u043a\u0430\u0442\u043e\u043c. \u041a\u043b\u0430\u0441\u0441\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0441\u043f\u043e\u0441\u043e\u0431 \u201c\u0443\u0431\u0438\u0442\u044c\u201d \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0412\u0441\u0435\u043c \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u044b\u0439","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-zashhishhat-proczessy-i-rasshireniya-yadra-v-macos","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-04-19T23:42:32+00:00","article:modified_time":"2020-04-19T23:42:32+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"78514","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:56:36","updated":"2022-09-28 22:19:40"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/78514","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=78514"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/78514\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/78515"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=78514"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=78514"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=78514"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}