Sandbox ��� mac os

Люблю иногда читать на сайте Apple описания их продуктов. Настоящие шедевры в некотором роде: вроде и примелькались со временем все эти «amazing», да «revolutionary», но, тем не менее, гипнотическое воздействие по прежнему велико. Смотришь, бывает, описание нового MacBook Air, и аж слезы к глазам подступают, эмоции теснят грудь, а душа полнится сладостным ощущением превосходства яблочной продукции.

И вот так, смакуя раздел «Security» на страничке Mac OS X, наткнулся я на крошечное упоминание применения в операционной системе sandbox-технологий. Однако, быстрый поиск показывает удивительную вещь: единственным более-менее известным приложением, применяющим сэндбоксинг, является Google Chrome и… все! Почему же так?

Как это работает

Что такое вообще есть sandbox? В переводе с английского — песочница, в данном случае для программ. Пользователь запускает приложение в изолированной среде, где оно (теоретически) никак не сможет навредить системе или выполнять определенные действия. В Mac OS X это реализуется при помощи трех компонентов:

— Sandbox-профиля, который представляет собой некое описание правил, которым должна подчиняться программа. Например, мы можем запретить ей выход в интернет, но разрешить запись в домашний каталог. Профилей можно создавать сколько угодно и выбирать нужный в зависимости от задачи.

— Команды sandbox-exec, запускающей приложение с определенным ранее sandbox-профилем.

— Расширения ядра sandboxd, реализующего сам функционал.

А теперь давайте заглянем в директорию /usr/share/sandbox. Что же мы видим?

Ага! Знакомые имена файлов, не правда ли? Можно предположить, что в Apple подумали о нашей с вами безопасности и загнали некоторые потенциально опасные службы в «песочницу». К сожалению, дальше создания профилей дело не пошло, и на практике все эти процессы запускаются в обычном режиме, хотя в соответствующих файлах конфигурации (например, в com.apple.syslogd.plist) можно включить запуск в sandbox-режиме.

Тем не менее, ничего не мешает нам заглянуть во внутренности какого-нибудь из этих профилей. Вот так, например, выглядит конфигурация сэндбокса для ntpd, службы синхронизации времени по протоколу NTP:

Для sandbox-профилей вместо привычного XML применяется форма записи параметров в виде описания правила, заключенного в круглые скобки. Сначала идет разрешение или запрет какого-либо действия (allow или deny), а потом описание самого действия. К примеру:

разрешает приложению любые сетевые соединения, а (deny signal) запрещает отсылать какие-либо системные сигналы.

Строчка (debug deny) указывает, что все отклоненные действия будут записаны в файл /var/log/system.log. Затем следует правило (deny default), запрещающее любую активность кроме той, что будет явно объявлена ниже.

(allow process*) разрешает запуск и остановку любых процессов, а (allow sysctl-read) — чтение параметров системы через sysctl.

Далее задаются разрешения на доступ к файловой системе. Видно, что ntpd может обращаться только к своим конфигурационным и временным файлам, причем их пути задаются регулярным выражением:

Предпоследняя строчка (allow time-set) разрешает изменение времени системы. Наконец, (import “bsd.sb”) импортирует правила из профиля bsd.sb, который является шаблоном для стереотипной системной службы.

На практике

Как можно заметить, ничего особенно сложного в конфигурации профиля нет. Поэтому возникает резонный вопрос — а почему бы не заключить в «песочницу» что-нибудь кроме стандартных демонов Mac OS X? К примеру, очевидным кандидатом является браузер Safari, ведь по количеству уязвимостей за 2010 год он уступает только Google Chrome.

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

К счастью, несколько разработчиков из компании ROMAB уже создали «бронированный» вариант Safari под названием IronSafari, который использует описанные выше механизмы для помещения приложения в изолированную среду. На их сайте также можно скачать аналогичные версии для Firefox, Adium и VLC.

Рассмотрим другой случай. Предположим, вы скачали откуда-то торрент, в котором лежит крохотный исполняемый файл, который почему-то очень хочется запустить. Однако, есть опасения, что это может нанести вред компьютеру. Можно, конечно, использовать виртуальную машину, но гораздо удобнее запустить его в сэндбоксе с несложным профилем, например вот таким:

В данном случае мы разрешаем запуск программы только из каталога /tmp/sandbox, в который, соответственно, и надо будет поместить исполняемый файл. Чтобы программы с графическим интерфейсом могли выполнять какие-то элементарные действия вроде отрисовки окна, необходимо также разрешить базовые вызовы к функциям Mach IPC (InterProcess Cimmunication, механизм взаимодействия программ, отдаленно похожий на сокеты в BSD), это задается параметром mach-lookup. Наконец, разрешено чтение любых файлов, начиная с корневого каталога и запись в /tmp.

Остается только запустить приложение в «песочнице». Как говорилось выше, для этого используется команда sandbox-exec:

Параметр –n указывает имя профиля, находящегося в каталоге /usr/share/sandbox.

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

Заключение

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

По крайней мере, маркетологи Apple с чистым сердцем могут констатировать факт того, что в Mac OS X есть простая и надежная система сэндбоксинга. Что уже само по себе есть не так плохо.

Источник

Using App Sandbox for macOS App

Sandboxing is the idea to keep data access controllable for the application.

Every coin has two sides. Let’s look at both.

Without Sandbox

Traditionally Mac Apps do not have Sandbox, developers have full access to all the resources in the computer. For instance, one could store and read files from any location.

Typically, files of the same type will be put together by default. Here are some common paths:

In this example, “com.abc.MyApp” is the bundle identifier of my application. I am using PINCache to store the cache, and persists that to disk space. You will notice that PINCache is storing files at the same level as the application Documents.

Issues with non-Sandbox

I know some developers like fully configurable environment. However, this approach is open to some problems:

1) Hacker

since the application can access the whole system, if it is injected by malicious code, the system may be hacked

2) S cattered file storage

Since documents, settings, cache are stored in different places, it is costing more development work. For instance, if I want to clean up the files to reset the application, I shall go to various locations to clean up.

Using App Sandbox

This concept becomes a norm as iOS was published. Every iOS app should come with its own sandbox. Thus developers should ask specific permissions in order to achieve other resources in the system.

In order to distribute apps thru Mac App Store, developers must turn on App Sandbox entitlement.

For instance, I am building an app that uses CloudKit to sync data. I shall tick the two boxes of Incoming and Outgoing Network connections. If I want to save the retrieved CloudKit records to a file in the Documents folder, I shall choose Read/Write access for “User Selected File”.

In Sandbox mode, all the files are stored in one container. For instance, the location in the previous example will become:

Issues with Sandbox

The main issues come from first-time settings. Besides, there are limitations to access the system resources.

1) Code Sign certificate

It’s always very annoying to handle the certificate and code sign issue. As entitlement is needed, developers should make sure the provisioning profile is generated correctly. In Xcode 8, it will manage the certificate, app ID, and provisioning for you. This is highly recommended. Sometimes, it still does not work. The simple solution is to turn off and back on again. The process will run again and configure for you.

2) Permissions

Make sure to get the appropriate permissions in Sandbox as you need. If you miss it, the application won’t give you any error, nor crashing the app. It takes great care to handle the options.

3) Conduct the setting using GUI

You can modify the entitlement file manually, but it will become out of sync with the Xcode interface. This may lead to code sign issue.

I am taking a challenge to write a post every day for 180 days. The content will be related to my life as a father, entrepreneur, developer and trainer.

Источник

Что такое «sandboxd» и что он делает в моем Mac

Открыли «Мониторинг системы» и обнаружили непонятный процесс под названием «sanboxd»? Давайте вместе разбираться что это такое. «sandboxd» — это демон (от анг. daemon), процесс, который выполняет определенную задачу в фоновом режиме, как правило у всех daemon-процессов буква «d» в окончании. Если конкретнее, sandboxd отвечает за работу процесса «песочницы». Запустите терминал и введите команду «man sandboxd» (без кавычек) и вы получите описание процесса:

sandboxd performs services on behalf of the Sandbox kernel extension.

«App Sandbox is an access control technology provided in macOS, enforced at the kernel level. It is designed to contain damage to the system and the user’s data if an app becomes compromised.»

Приложение sandbox — это технология контроля доступа в MacOS, которая действует на уровне ядра системы. Она предназначена, уберечь систему и данные пользователя от повреждений, на случай если приложение будет скомпрометировано.

Приложения, которые работают из «песочницы» делают запрос на доступ к файлам и функциям системы, например, на доступ к веб-камере — этот процесс добавляет дополнительный уровень безопасности ОС. Использование «песочницы» является одним из самых основных требований к приложениям, которые распространяются через Mac App Store — это одна из причин по которой некоторого софта нет в Mac App Store. Процесс «sandboxd» не расходует много системных ресурсов.

И самое главное, не забудьте подписаться на наш канал в Telegram

Источник

Использование Sandbox на Mac OS X Server для изоляции пользовательских веб-приложений

Небольшое лирическое введение

Появился как-то у меня заказчик, который захотел странного, а именно простой в управлении хостинг, который позволил бы пользователям загружать и изолированно запускать веб-приложения на базе микрофреймворка Camping. И я ему сделал его на предложенном виртуальном сервере под управлением FreeBSD 9.0 с помощью nginx, thin server, и ezjail как средства управления jail’ами (все довольно тривиально, но если будет кому-нибудь интересно — опишу). А через неделю заказчик признался мне, что он вообще-то поклонник решений от Apple и хотел бы видеть ту же систему работающей на его основном сервере под управлением Mac OS X. И я с радостью согласился адаптировать решение, так как раньше не имел удовольствия соприкоснуться с этой системой и хотел ее хоть немного изучить. Было только одно «но» — на MacOS X Server нет jail(8). Так вот, в поисках решения для максимально безопасного запуска загружаемого пользователем приложения (я не мог и не хотел использовать chroot по ряду причин) я нашел чрезвычайно гибкий и прекрасно интегрированный в систему инструмент — Sandbox.

Построение основы для хостинга

Sandbox

Sandbox оказался удивительным инструментом. В чем-то напоминающий AppArmor, в чем-то SeLinux, а в чем-то совершенно уникальный способ держать приложение «в узде» и не давать ему больше возможностей, чем ему реально надо для работы. Способ, которым применяются политики Sandbox — это запуск приложения в «песочнице» с передачей в качестве опции пути к заранее написанному для этого приложения профилю (текстовому файлу, содержащему описание политик безопасности). К некоторому сожалению, Sandbox несколько беднее документирован, чем я привык (подробность FreeBSD Handbook развращает), однако в сети нашлось немало примеров написания конкретных профилей, что значительно облегчило задачу. Мне было необходимо написать профиль для легкого сервера ruby-приложений Thin, каким именно образом он используется, я опишу ниже. Любой профиль начинается с декларации версии языка разметки и, желательно, политики по умолчанию (очевидно запретительного характера в нашем случае). Все директивы или их наборы заключены в круглые скобки. Имена политик (или «операции» — operations) поддерживают маски (wildcard — *), расширяющие сферу применения правил. Фильтры (filters, их всего 6: path network file-mode xattr mach signal) задаются согласно правилам (о синтаксисе смотрите подробнее здесь). Например, path может задаваться строкой буквально (literal), регулярным выражением (regex) и, да простят меня за кальку с английского, «подпутем» (subpath). Все комментарии начинаются с символа ‘;’:

Для запуска пользовательских Camping-приложений был выбран Thin. Почему Thin, а не Mongrel, Passenger, uWSGI или что-то еще? Он поддерживал все необходимые функции и оказался не очень требовательным к ресурсам (серьезных исследований, впрочем, я не проводил). Кроме того, я не смог придумать как приготовить Passenger таким образом, чтобы он как-то изолированно запускал приложения, хотя вероятнее всего это как-то возможно (я не беру вариант с запуском многих копий nginx от лица разных пользователей, такой вариант рассматривался, но был отметен) и если кто-нибудь в комментариях предложит работающее решение, буду рад ознакомиться. Мой комбайн-фаворит для практически любых дел — uWSGI из последнего tip — отказался нормально работать с rack-приложениями на FreeBSD (о чем был оповещен разработчик и все было починено в течение пары дней, но, увы, поезд ушел), а на MacOS X вообще не собирался ни в какую. Mongrel попробовать не успели, остановившись на Thin, уж больно хорошо пошло с ним дело. Итак, вот строка запуска некоего основанного на Camping rack-приложения в контейнере Thin:

Опция ‘tag’ дает приятную возможность увидеть в top и ps кто именно скушал все ресурсы (системный пользователь используется один для всех запусков).

Nginx

Все тривиально. Никакой статики. Имя виртуального «пользователя» хостинга эквивалентно выделенному ему поддомену:

Скриптовая обвязка

Для разработки обвязки я использовал sh, потому что люблю простые и переносимые вещи. Критика приветствуется, скрипты остались довольно сыроватыми. Предполагается, что скрипты запускаются от имени суперпользователя (root).
Управление виртуальными пользователями — users_management.sh:

Управление пользовательскими приложениями — application_management.sh:

Заключение

Sandbox это достаточно мощная «песочница», которая, я думаю, может послужить популяризации Mac OS X в качестве серверной платформы.

Источник