Mac os sandbox что это

Что такое «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

Источник

Люблю иногда читать на сайте 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 есть простая и надежная система сэндбоксинга. Что уже само по себе есть не так плохо.

Источник

Использование 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 в качестве серверной платформы.

Источник

Внутри песочницы: как Apple планирует сделать Mac App Store более безопасным

Приближается срок, установленный Apple для вступления в силу нового пункта политики безопасности компании, против которого высказывались в прошлом году многие разработчики – все приложения из ассортимента магазина Mac App Store будут защищены механизмом работы в Sandboxing (песочнице).

После открытия Mac App Store в январе 2011 года Apple впервые заявила, что к ноябрю песочница (изолированная программная среда) станет обязательной для всех приложений, продаваемых в магазине. После этого сроки перенесли до начала марта следующего года, отчасти из-за жалоб со стороны многих разработчиков, отчасти из-за проблем в работе самого механизма.

В мобильной платформе Apple iOS с самого начала используется режим песочницы, который предотвращает распространение вирусов, вредоносных программ и решает другие серьезные вопросы безопасности, которые существуют у владельцев мобильных устройств на базе других платформ – таких, как Symbian, Palm OS или Android.

Песочница для безопасности

Вначале Apple начала добавлять функции защитной песочницы в Mac OS X Leopard. Песочница обеспечивает операционной системе контроль над приложением и ограничивает его возможности. Основная защитная задача песочницы – не дать приложению делать то, что оно практически не должно делать, тем самым предотвратив возможные вредоносные действия с его стороны.

Apple включила поддержку режима песочницы в некоторые собственные приложения, идущие в комплекте с OS X, включая Safari Web Content (это помогает уменьшить ущерб от плагина Adobe Flash, когда он находится под угрозой или выходит из строя).

Preview и TextEdit также работают в песочнице: Preview изолирует свой PDF-рендеринг во вторичной песочнице, чтобы свести на нет все возможные угрозы внутри PDF. QuickTime защищает песочницей свои видео-декодеры, решая задачи защиты при помощи VTDecoderXPCService.

С появлением новой Mac OS X Lion системная поддержка режима песочницы усложнилась, чтобы быть используемой в отношении многих сторонних приложений. Изначально Apple предполагала, что режим песочницы будет касаться всех приложений магазина Mac App Store, но потом дала разработчикам отсрочку для изучения некоторых вопросов, которые тогда создавали больше проблем, чем решали. Конечным сроком введения нового правила безопасности в магазин приложений стало 1 марта 2012 года, которое наступит уже через несколько недель.

Система разрешений для приложений

Песочница – это модель безопасности для приложений, которая работает cхоже с файловой системой, основанной на пользовательских разрешениях. Когда пользователь начинает работать с компьютером, у его аккаунта есть определенные ограничения – к примеру, запрещающие ему удалять определенные системные файлы. Песочница делает с приложениями то же самое, что делает система прав доступа к файлам с файлами: она только обеспечивает доступ к некоторым функциям, набор которых определен заранее. Разрешения песочницы называются «entitlements» (но они имеют мало общего с моделью разрешений Android). Существует больше двух десятков разрешений для приложений, находящихся в песочнице Mac OS X Lion, которые дают приложениям разные права – к примеру, возможность читать локальные файлы, прослушивать сетевые соединения, иметь доступ к камере FaceTime для съемки изображений и пр.

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

Защита от повреждений

При помощи жесткого кодирования возможностей приложения, соответствующих установленному набору разрешений, приложения становятся более безопасными, так как ошибки (нечаянные или сознательные), которые дают возможность приложению сделать то, чего оно не должно делать (к примеру, читать личную документацию пользователя), просто не работают в песочнице. Также этот способ защищает систему от приложений, зараженных вирусами или прочими вредоносными программами и способных нанести ущерб разного размера.

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

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

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

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

Сроки приближаются

С одной стороны, Apple стремится избавить разработчиков от лишней работы, но с другой стороны хочет поскорее применить для программного обеспечения Mac (ассортимент которого постоянно растет) новые функции безопасности. С 1 марта добавление режима песочницы станет еще одним обязательным требованием для разработчиков, которые хотят продавать свои программные продукты через магазин Mac App Store.

Apple еще не применила режим песочницы для своих приложений iLife и iWorks, сосредоточившись изначально на ограничении рамками песочницы приложений и процессов, которые запускают плагины или кодеки (таких, как Safari, Quick Look, QuickTime и Preview). В следующем месяце все изменится – сроки коснутся как продуктов сторонних разработчиков, так и собственных приложений компании.
Apple также занялась усовершенствованием своих программных пакетов и отдельных приложений поддержкой 64-бит, начав с тех, которые больше всего выиграли от смены архитектуры.

Источник