Как заблокировать процесс mac os

Завершение работы приложения или процесса в приложении «Мониторинг системы» на Mac

В Мониторинге системы можно завершить любой процесс, даже если он зациклился или не отвечает. Можно также отправить процессу сигнал прерывания. При попытке завершить процесс, владельцем которого Вы не являетесь, может потребоваться войти в систему в качестве администратора.

В приложении «Мониторинг системы» на Mac в списке «Имя процесса» выберите приложение или процесс, которые нужно завершить. Процесс, который не отвечает на запросы, помечается надписью «(не отвечает)».

Примечание. Список «Имя процесса» недоступен на странице «Кэш».

Нажмите кнопку «Остановить» в левом верхнем углу окна Мониторинга системы (или воспользуйтесь панелью Touch Bar).

Выберите один из следующих вариантов.

Завершить. То же самое происходит, когда Вы выбираете меню «Файл» > «Завершить» в приложении. Процесс будет завершен, когда это можно будет сделать безопасно. Если завершение процесса может привести к потере данных или помешать работе другого приложения, процесс не будет завершен.

Завершить принудительно. Процесс будет завершен немедленно. Если к процессу привязаны открытые файлы, Вы можете потерять данные. Если процесс используется другим приложением или процессом, в их работе могут возникнуть неполадки.

Чтобы узнать, используется ли процесс другим процессом, выберите «Вид» > «Все процессы, иерархически».

Чтобы отправить сигнал процессу, выберите процесс в списке процессов, затем выберите «Вид» > «Послать сигнал процессу», выберите сигнал во всплывающем меню, затем нажмите «Отправить».

Источник

Блокирование подключений к Mac с помощью брандмауэра

Брандмауэр может защитить Mac от нежелательных контактов, инициированных другими компьютерами при подключении к Интернету или сети. Однако Ваш Mac по-прежнему может разрешать доступ через брандмауэр для некоторых служб и приложений. Например:

Если Вы включили службу общего доступа, например общий доступ к файлам, macOS открывает определенный порт, через который эта служба будет обмениваться данными.

Приложение, служба или другая система может запросить и получить разрешение на доступ через брандмауэр или может быть подписана надежным сертификатом, и поэтому ему будет дано разрешение на доступ.

Для повышения контроля можно выбрать приложения и службы и указать, предоставлять ли им доступ через брандмауэр.

Включение брандмауэра

На Mac выберите меню Apple

> «Системные настройки», нажмите «Защита и безопасность», затем нажмите «Брандмауэр».

Если слева внизу отображается запертый замок , нажмите его, чтобы разблокировать панель настроек.

Нажмите «Включить брандмауэр».

Чтобы задать дополнительные настройки безопасности, нажмите «Параметры брандмауэра» и выполните одно из следующих действий:

Разрешить подключение только определенным приложениям и службам. Нажмите кнопку «Добавить» , затем выберите приложение или службу в появившемся диалоговом окне.

Разрешить подключение только важным приложениям и службам. Установите флажок «Блокировать все входящие подключения».

Автоматически разрешать встроенному ПО входящие подключения. Установите флажок «Автоматически разрешать встроенному ПО входящие подключения».

Автоматически разрешить загруженным подписанным программам принимать входящие подключения. Установите флажок «Автоматически разрешать загруженному подписанному ПО входящие подключения».

Можно включить режим невидимости, чтобы затруднить хакерам и вредоносным программам обнаружение Вашего Mac. Выберите «Включить режим невидимости»

Настройка брандмауэра для служб и приложений

На Mac выберите меню Apple

> «Системные настройки», нажмите «Защита и безопасность», затем нажмите «Брандмауэр».

Если слева внизу отображается запертый замок , нажмите его, чтобы разблокировать панель настроек.

Нажмите «Параметры брандмауэра».

Если кнопка «Параметры брандмауэра» неактивна, сначала нажмите «Включить брандмауэр», чтобы включить брандмауэр на компьютере Mac.

Нажмите кнопку «Добавить» под списком служб, затем выберите службы или приложения, которые хотите добавить. Когда приложение будет добавлено, нажимайте стрелки вверх и вниз рядом с ним, чтобы разрешить или заблокировать подключения через брандмауэр.

Блокировка доступа через брандмауэр может негативно повлиять на работу приложения или другого программного обеспечения, зависящего от такого доступа.

Важно! Некоторые приложения, которые не отображаются в списке, могут получать доступ через брандмауэр. К их числу могут также относиться системные приложения, службы и процессы, снабженные цифровой подписью, которые автоматически открываются другими приложениями. Чтобы заблокировать доступ таких программ, добавьте их в список.

Если Ваш Mac обнаружит попытку подключения к приложению, которую Вы не добавляли в список и которому не разрешали доступ, появится окно предупреждения с вопросом, хотите ли Вы разрешить подключение по сети или через Интернет. Пока Вы не предпримете действий, это сообщение остается на экране, а все попытки подключения к приложению будут блокироваться.

Источник

Как защищать процессы и расширения ядра в macOS

Привет, Хабр! Сегодня мне хотелось бы поговорить о том, как можно защитить процессы от посягательств злоумышленников в macOS. Например, это полезно для антивируса или системы резервного копирования, особенно в свете того что под macOS существует сразу несколько способов “убить” процесс. Об этом и о методах защиты читайте под катом.

Классический способ “убить” процесс

Всем известный способ “убить” процесс — послать сигнал об SIGKILL процессу. Через bash можно вызвать стандартные “kill -SIGKILL PID” или “pkill -9 NAME” для убийства. Команда “kill” известна еще со времен UNIX и доступна не только в macOS, но и на других UNIX-like системах.

Также как и в UNIX-like системах, macOS позволяет перехватить любые сигналы к процессу кроме двух — SIGKILL и SIGSTOP. В этой статье будет в первую очередь рассматриваться сигнал SIGKILL, как сигнал, порождающий убийство процесса.

Специфика macOS

В macOS системный вызов kill в ядре XNU вызывает функцию psignal(SIGKILL. ). Попробуем посмотреть, какие еще действия пользователя в userspace может вызвать функцию psignal. Отсеим вызовы функции psignal в внутренних механизмах ядра (хотя и они могут быть нетривиальными, но оставим их для другой статьи 🙂 — проверка подписи, ошибки памяти, обработка exit/terminate, нарушение защиты файлов и т.п.

Начнем обзор с функции и соответствующего системного вызова terminate_with_payload. Видно, что помимо классического вызова kill существуют альтернативный подход, который специфичен для операционной системы macOS и не встречается в BSD. Принципы работы обоих системных вызовов также близки. Они представляют собой прямые вызовы функции ядра psignal. Также обратим внимание, что перед убийством процесса производится проверка “cansignal” – может ли процесс отправить сигнал другому процессу, система не допускает любому приложению убивать системные процессы например.

launchd

Стандартный способ создания демонов на запуске системы и контролировать их время жизни — launchd. Обращу внимание на то, что исходники приведены для старой версии launchctl до macOS 10.10, примеры кода приведены в качестве иллюстрации. Современный launchctl отправляет сигналы launchd через XPC, логика launchctl перенесена в него.

Рассмотрим как именно производится остановка приложений. Перед отправкой сигнала SIGTERM, приложение пытаются остановить при помощи системного вызова “proc_terminate”.

Под капотом proc_terminate, несмотря на свое название, может отправлять не только psignal c SIGTERM, но и SIGKILL.

Косвенное убийство — ограничение на ресурсы

Более интересный случай можно увидеть в другом системном вызове process_policy. Стандартное использование этого системного вызова — ограничения ресурсов приложений, например для индексера ограничение на квоту процессорного времени и памяти, чтобы система не существенно замедлялась от действий кэширования файла. Если приложение достигло ограничения на ресурсы, как можно увидеть из функции proc_apply_resource_actions, то процессу отправляется сигнал SIGKILL.

Несмотря на то, что данный системный вызов может потенциально производить убийство процесса, система не проверяла адекватно права процесса, вызывающего системный вызов. На самом деле проверка существовала, но достаточно использовать альтернативный флаг PROC_POLICY_ACTION_SET для обхода этого условия.

Отсюда если “ограничить” квоту использования CPU приложением (например разрешить выполняться только 1 ns),, то можно произвести убийство любого процесса в системе. Так, зловред может убить любой процесс на системе, в том числе и процесс антивируса. Также интересен эффект, который получается при убийстве процесса с pid 1 (launchctl) — kernel panic при попытке обработать сигнал SIGKILL 🙂

Как решать проблему?

Самый прямолинейный способ запретить убивать процесс — подменить указатель на функцию в таблице системных вызовов. К сожалению, данный способ является нетривиальным по многим причинам

Во-первых, символ, который отвечает за положение sysent в памяти, не только является приватным символа ядра XNU, но и не может быть найден в символах ядра. Придется использовать эвристические методы поиска, например динамическое дизассемблирование функции и поиск указателя в ней.

Во-вторых, структура записей в таблице зависит от флагов, с которыми было собрано ядро. Если объявлен флаг CONFIG_REQUIRES_U32_MUNGING, то размер структуры будет изменен — добавлено дополнительное поле sy_arg_munge32. Необходимо производить дополнительную проверку на то, с каким флагом было скомпилировано ядро, как вариант сверять указатели на функции с известными.

К счастью, в современных версиях macOS Apple предоставляет новое API для работы с процессами. Endpoint Security API позволяет клиентами авторизировать многие запросы к другим процессам. Так, можно заблокировать любые сигналы к процессы, в том числе сигнал SIGKILL при помощи вышеупомянутого API.

Аналогично в ядре можно зарегистрировать MAC Policy, который предоставляет метод защиты от сигналов (policy proc_check_signal), однако API не поддерживается официально.

Защита расширения ядра

Помимо защиты процессов в системе обязательно необходима и защита самого расширения ядра (kext). macOS предоставляет для разработчиков фреймворк для удобной разработки драйверов устройств IOKit. Помимо предоставления средств работы с устройствами, IOKit обеспечивает методы стекирования драйверов (driver stacking) при помощи экземпляров классов C++. Приложение в userspace сможет “найти” зарегистрированный экземпляр класса для установления связи kernel-userspace.

Для обнаружения количества экземпляров классов в системе существует утилита ioclasscount.

Любое расширение ядра, которое желает зарегистрироваться в стеке драйверов, обязано объявить класс, унаследованный от IOService, например, my_kext_ioservice в данном случае.Подключение пользовательских приложений вызывает создание нового экземпляра класса, который наследуется от IOUserClient, в примере my_kext_iouserclient.

При попытке выгрузки драйвера из системы (команда kextunload) вызывается виртуальная функция “bool terminate(IOOptionBits options)”. Достаточно вернуть false на вызове функции terminate при попытке выгрузки, чтобы запретить kextunload.

Флаг IsUnloadAllowed может быть выставлен IOUserClient при загрузке. При ограничении на загрузку команда kextunload вернет следующий вывод:

Аналогичную защиту необходимо произвести и для IOUserClient. Экземпляры классов можно выгрузить при помощи userspace функции IOKitLib “IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t description);”. Можно возвращать false на вызове команды “terminate” пока userspace приложение не “умрет”, то есть не будет вызов функции “clientDied”.

Защита файлов

Для защиты файлов достаточно использовать Kauth API, который позволяет ограничивать доступ к файлам. Apple предоставляет разработчикам нотификации о различных событиях в scope, для нас важны операции KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA и KAUTH_VNODE_DELETE_CHILD. Ограничивать доступ к файлам проще всего по пути — используем API “vn_getpath” для получения пути к файлу и производим сравнение префикса пути. Заметим, что для оптимизации переименования путей папок с файлами, система не авторизирует доступ к каждому файлу, но только к самой папке, которую переименовали. Необходимо производить сравнение родительского пути и ограничивать KAUTH_VNODE_DELETE для нее.

Недостатком данного подхода может стать низкая производительность при возрастании количества префиксов. Для того, чтобы сравнение не было равно O(prefix*length), где prefix — количество префиксов, length — длина строки, можно использовать детерминированный конечный автомат (ДКА), построенный по префиксам.

Рассмотрим способ построения ДКА для данного набора префиксов. Инициализируем курсоры на начало каждого префикса. Если все курсоры указывают на один и тот же символ, то увеличим каждый курсор на один символ и запомним, что длина одинаковой строчки больше на единицу. Если существует два курсора, символы под которыми разные, разделим курсоры на группы по символу, на которые они указывают и повторим алгоритм для каждой группы.

В первом случае (все символы под курсорами одинаковые) получаем состояние ДКА, которое имеет только один переход по одинаковой строчке. Во втором случае, получаем таблицу переходов размером 256 (кол-во символов и максимальное количество групп) в последующие состояния, полученные при рекурсивном вызове функции.

Рассмотрим пример. Для набора префиксов (“/foo/bar/tmp/”, “/var/db/foo/”, “/foo/bar/aba/”, “foo/bar/aac/”) можно получить следующий ДКА. На рисунке указаны только переходы, ведущие в другие состояния, другие переходы не будут являться конечными.

При прохождении по состояниям ДКА может оказаться 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 Product Security Team и была исправлена в macOS 10.14.5 (https://support.apple.com/en-gb/HT210119).

Все это можно сделать только в том случае, если ваша утилита была официально установлена в ядро. То есть для внешнего и нежелательного ПО нет таких лазеек. Однако, как вы видите, даже для защиты легитимных программ, таких как антивирус и система резервного копирования, приходится потрудиться. Но зато теперь новые продукты Acronis для macOS будут иметь дополнительную защиту от выгрузки из системы.

Источник