Песочница — это новый легковесный инструмент в ОС Windows, позволяющий запускать приложения в безопасном изолированном окружении.
Случалось ли Вам оказаться в ситуации, когда необходимо запустить какую-то программу, но Вы не совсем уверены в источнике её происхождения? Или другой пример — необходимость проверить что-то на «чистой» версии Windows. Во всех подобных случаях раньше был только один выход — установить ОС на отдельную физическую или виртуальную машину и провести нужный эксперимент. Но это больше не так.
Microsoft разработал новый механизм под названием Песочница (eng. Windows Sandbox). Это изолированное временное окружение, в котором Вы можете запускать подозрительное программное обеспечение без риска навредить своему ПК. Любое ПО, установленное в Песочнице, остаётся только в Песочнице и не может взаимодействовать с основной ОС. Как только Вы закрываете Песочницу — всё её содержимое безвозвратно уничтожается.
Вот основные особенности Песочницы:
- Это часть ОС Windows. Если у Вас Windows 10 Pro или Enterprise, то Вы уже можете начать ею пользоваться.
- С чистого листа. При каждом запуске Песочницы Вы получаете одно и то же, чистое, неизменное окружение. В точности такое, какой была Ваша ОС сразу после её установки.
- Никаких следов. При закрытии Песочницы уничтожаются все установленные в ней приложения, все созданные там файлы. Закрыли Песочницу — не осталось никаких следов её существования.
- Безопасность. Используется аппаратная виртуализация, которая использует гипервизор для запуска отдельного ядра ОС и изолирует его от Вашей основной ОС
- Эффективность. Используется интегрированный планировщик задач, умное управление памятью, виртуальный GPU.
Системные требования
- Windows 10 Pro или Enterprise, билд 18305 или выше
- Архитектура AMD64
- Включенная в BIOS виртуализация
- Минимум 4 ГБ (рекомендовано 8 ГБ) оперативной памяти
- Минимум 1 ГБ свободного места на диске (рекомендуется SSD)
- Процессор с двумя ядрами (рекомендуется 4 с поддержкой hyper-threading)
Быстрый старт
1. Установите Windows 10 Pro или Enterprise, билд 18305 или выше
2. Включите виртуализацию:
- Если Вы работаете на физической машине — сделайте это в BIOS
- Если Вы работаете на виртуальной машине — используйте следующую PowerShell команду:
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
3. Откройте (через Панель Управления) список установленных компонентов Windows и включите в нём Песочницу. Нажмите ОК. Если увидите запрос на перезагрузку компьютера — подтвердите его.
4. Запустите Песочницу из меню Пуск. Разрешите повышение прав для её процесса.
5. Скопируйте (через буфер обмена) в Песочницу бинарник, который хотите запустить.
6. Запустите бинарник в Песочнице. Если это инсталлятор — пройдите процедуру установки и запустите установленное приложение.
7. Используйте приложение по назначению.
8. Когда закончите — просто закройте Песочницу. Всё её содержимой будет удалено.
9. Опционально — можете убедиться, что в Вашей основной ОС ничего не изменилось.
Что под капотом у Песочницы
Песочница Windows построена на технологии, которая называется Windows Containers. Контейнеры разрабатывались (и давно используются) для работы в облаке. Microsoft взял уже достаточно зрелую и протестированную технологию и доработал её для пользователей десктопной Windows.
Среди ключевых адаптаций можно отметить:
Динамически генерируемый образ
Песочница является хотя и легковесной, но всё же виртуальной машиной. И, как любой виртуальной машине, ей требуется образ, с которого она может загрузится. Важнейшей особенностью Песочницы является то, что Вам не нужно откуда-то качать или создавать этот образ. Он создастся на лету, из файлов вашей текущей ОС Windows.
Мы хотим всегда получить одно и то же «чистое» окружение для Песочницы. Но есть проблема: некоторые системные файлы могут меняться. Решением было создание «динамически генерируемого образа»: для изменённых файлов в него будут включаться их оригинальные версии, но вот неизменные файлы физически в этот образ входить не будут. Вместо них будут использоваться ссылки на реальные файлы на диске. Как показала практика — такими ссылками будут большинство файлов в образе. Лишь малая их часть (около 100 МБ) войдут в образ полностью — это и будет его размер. Более того, когда Вы не используете Песочницу, эти файлы хранятся в сжатом виде и занимают около 25 МБ. При запуске Песочницы они разворачиваются в тот самый «динамический образ» размером около 100 МБ.
Умное управление памятью
Управление памятью для Песочницы — ещё одно важное усовершенствование. Гипервизор позволяет запускать на одной физической машине несколько виртуальных и это, в общем, неплохо работает на серверах. Но, в отличии от серверов, ресурсы обычных пользовательских машин значительно более ограничены. Для достижения приемлемого уровня производительности Microsoft разработал специальный режим работы памяти, при котором основная ОС и Песочница могут с некоторых случаях использовать одни и те же страницы памяти.
В самом деле: поскольку основная ОС и Песочница запускают один и тот же образ ОС, то большинство системных файлах в них будут одни и те же, а значит нет смысла дважды загружать в память одинаковые библиотеки. Можно сделать это один раз в основной ОС, а когда тот же файл понадобится в памяти Песочнице — ей можно дать ссылку на ту же страницу. Конечно, требуются некоторые дополнительные меры для обеспечения безопасности подобного подхода, но Microsoft позаботилась об этом.
Интегрированный планировщик
В случае использования обычных виртуальных машин гипервизор контролирует работу виртуальных процессоров, работающих в них. Для Песочницы была разработана новая технология, которая называется «интегрированный планировщик», которая позволяет основной ОС решать когда и сколько ресурсов выделить Песочнице. Работает это так: виртуальный процессоры Песочницы работают как потоки внутри процесса Песочницы. В итоге они имеют те же «права», что и остальные потоки в вашей основной ОС. Если, к примеру, у вас работают какие-то высокоприоритетные потоки, то Песочница не будет отнимать у них много времени для выполнения своих задач, которые имеют нормальный приоритет. Это позволит пользоваться Песочницей, не замедляя работу критически важных приложений и сохраняя достаточную отзывчивость UI основной ОС, аналогично тому, как работает Linux KVM.
Главной задачей было сделать Песочницу с одной стороны просто обычным приложением, а с другой — дать гарантию её изоляции на уровне классических виртуальных машин.
Использование «снимков»
Как уже говорилось выше, Песочница использует гипервизор. Мы по сути запускаем одну копию Windows внутри другой. А это означает, что для её загрузки понадобится какое-то время. Мы можем тратить его при каждом запуске Песочницы, либо сделать это лишь раз, сохранив после загрузки всё состояние виртуальной ОС (изменившиеся файлы, память, регистры процессора) на диске. После этого мы сможем запускать Песочницу из данного снимка, экономя при этом время её старта.
Виртуализация графики
Аппаратная виртуализация графики — это ключ к плавному и быстрому пользовательскому интерфейсу, особенно для «тяжелых» в плане графики приложений. Однако, классические виртуальные машины изначально ограничены в возможностях напрямую использовать все ресурсы GPU. И здесь важную роль выполняют средства виртуализации графики, которые позволяют преодолеть данную проблему и в какой-то форме использовать аппаратную акселерацию в виртуальном окружении. Примером такой технологии может быть, например, Microsoft RemoteFX.
Кроме того, Microsoft активно работала с производителями графических систем и драйверов для того, чтобы интегрировать возможности виртуализации графики непосредственно в DirectX и WDDM (модель драйверов в ОС Windows).
В результате графика в Песочнице работает следующим образом:
- Приложение в Песочнице использует графические функции обычным образом, не зная кто и как будет их выполнять
- Графическая подсистема Песочницы, получив команды отрисовки графики, передаёт их основной ОС
- Основная ОС, получив команды отрисовки графики, воспринимает их так, как будто они пришли от локально запущенного приложения и соответствующим образом выполняет их, выделяя и управляя необходимыми ресурсами.
Это процесс можно изобразить так:
Это позволяет виртуальному окружению получать полноценный доступ к аппаратно акселерируемой графике, что даёт как прирост производительности, так и экономию некоторых ресурсов (например, заряда батареи для ноутбуков) в следствие того, что для отрисовки графики больше не используются тяжелые расчёты на CPU.
Использование батареи
Песочница имеет доступ к информации о заряде батареи и может оптимизировать свою работу для его экономии.
Отзывы и сообщения о проблемах
В любой новой технологии могут быть баги. Microsoft просит присылать сообщения о них и предложения новых фич через Feedback Hub.
Информационной безопасности много не бывает, особенно в нынешних реалиях, когда киберпреступники стремятся быть на шаг впереди новейших средств обнаружения зловредного ПО и используют всё более изощрённые методы хакерских атак. В таких условиях одного лишь установленного на ПК антивируса явно недостаточно. Необходим комплексный подход к обеспечению противодействия современным цифровым угрозам, реализовать который можно с помощью так называемых программ-песочниц (от англ. Sandbox).
Ключевое преимущество Sandbox-приложений — высокий уровень надёжности и безопасности, а также простота использования. Они позволяют буквально в два-три клика разворачивать изолированные среды, в которых можно без опаски запускать любые программы без риска навредить установленной на компьютере операционной системе или повлиять на стабильность её работы. Благодаря этому песочницы можно использовать для запуска недоверенного или потенциально опасного софта, просмотра документов и файлов сомнительного происхождения, а также безопасного веб-сёрфинга в интернете, в том числе для проверки подозрительных электронных писем, ссылок и сетевых ресурсов.
Способов применения технологиям Sandbox можно найти множество. Самое главное — подобрать подходящий инструментарий, определиться с выбором которого поможет наша подборка песочниц для широко востребованной во всём мире платформы Windows.
Источник изображения: Sentavio / freepik.com
⇡# Windows Sandbox
Разработчик: Microsoft.
Сайт продукта: microsoft.com/windows.
Стоимость: бесплатно (включена в состав ОС).
Начнём обзор с самого простого и доступного варианта — встроенной песочницы Windows 10/11, поставляемой в комплекте с операционной системой редакций Pro и Enterprise.
В основу Windows Sandbox положены гипервизор Hyper-V и технологии контейнеризации. Как следствие, для запуска песочницы необходим ПК на базе процессора с поддержкой аппаратной виртуализации и объёмом оперативной памяти не менее 4 Гбайт. По умолчанию функция Sandbox отключена в системе. Для её активации необходимо через панель управления открыть меню «Компоненты Windows», выставить галочку напротив пункта «Песочница Windows», дождаться установки необходимых системных файлов и перезагрузить ОС.
Windows Sandbox представляет собой виртуальную машину с облегчённой копией ОС, все вносимые изменения в которую автоматически откатываются при закрытии изолированной среды, и при каждом запуске песочница запускается «с нуля» в чистом виде. Такой подход освобождает от необходимости удалять установленные в виртуальном окружении программы и здорово экономит время.
В отличие от классической виртуальной машины при использовании песочницы нет необходимости заморачиваться самостоятельной установкой, настройкой и лицензированием отдельной копии Windows. Второй важный момент — в Sandbox используется динамически создаваемый образ ОС, который формируется на основе файлов и DLL-библиотек установленной на компьютере системы. Благодаря этому виртуальная машина с песочницей занимает меньше места на диске и потребляет гораздо меньше ресурсов.
Запускать Windows Sandbox можно только в одном экземпляре. Для управления настройками песочницы и защищённой среды (включение/выключение виртуализации графического процессора, поддержки сети, общих папок с хост-системой и буфера обмена данными, запуска скриптов) допускается использование конфигурационных файлов с расширением .wsb. Об особенностях работы с ними можно узнать на этой странице сайта Microsoft.
⇡#Microsoft Defender Application Guard
Разработчик: Microsoft.
Сайт продукта: microsoft.com/windows.
Стоимость: бесплатно (включена в состав ОС).
Если песочницу планируется использовать только для защищённого веб-сёрфинга, то вместо установки Windows Sandbox можно ограничиться модулем Application Guard, функционирующим в связке с антивирусом Microsoft Defender.
Чтобы воспользоваться Application Guard, необходимо в окне «Компоненты Windows» активировать соответствующий пункт меню, дождаться установки системных файлов и перезапустить ОС.
После перезагрузки компьютера в поставляемом с Windows браузере Edge появится возможность запускать интернет-обозреватель в изолированной среде, использующей технологии виртуализации Hyper-V. При включённом режиме Application Guard можно смело открывать любые сайты и не опасаться, что размещённый на них вредоносный код сможет выйти за пределы песочницы и нанести вред системе.
О том, что браузер действительно запущен в изолированном окружении, свидетельствует значок Application Guard на панели инструментов Microsoft Edge.
Помимо Edge песочницу можно использовать в Google Chrome и Mozilla Firefox — для этого необходимо установить в браузер расширение Application Guard, доступное для скачивания в магазине Chrome Web Store и на сайте Firefox Browser Add-ons.
Application Guard также поддерживает интеграцию с пакетом Microsoft 365 и позволяет открывать в безопасной среде офисные документы. Функция крайне полезная, но, увы, доступная только в решениях софтверного гиганта для корпоративного сегмента рынка. По этой причине мы оставляем её за рамками нашего обзора.
⇡#Sandboxie
Разработчик: Дэвид Ксанатос (David Xanatos).
Сайт продукта: sandboxie-plus.com.
Стоимость: бесплатно с лимитированным набором функций (для снятия ограничений предлагается приобрести сертификат стоимостью от $20).
Ещё одно доступное широкой аудитории решение для работы с приложениями в изолированной среде. Отличительными особенностями Sandboxie являются открытый исходный код, поддержка Windows 7/8.1/10/11 и неограниченного количества песочниц, а также огромное множество всевозможных настроек, позволяющих гибко конфигурировать параметры защищённых сред. Наличие на компьютере средств аппаратной виртуализации не требуется, что является несомненным плюсом программы. Кроме того, Sandboxie можно установить как портативное приложение и запускать с флешки на любом компьютере.
С помощью Sandboxie можно создавать списки автоматически запускаемых в песочнице исполняемых файлов, настраивать политики доступа приложений к системным компонентам Windows и ресурсам компьютера, конфигурировать правила встроенного брандмауэра для каждого процесса и осуществлять скрупулёзный мониторинг всех действий программ и вносимых ими изменений. Для каждой из песочниц Sandboxie позволяет закреплять индивидуальный набор настроек. Поддерживается интеграция с рабочим окружением Windows и быстрый запуск приложений в песочнице через контекстное меню проводника. Для наглядности окна «изолированных» программ обводятся жёлтой рамкой.
В отличие от прочих представленных на рынке приложений-песочниц Sandboxie требует грамотного подхода к конфигурированию изолированных сред, и неправильные настройки последних могут серьёзно ослабить защиту от вредоносного софта. По этой причине мы рекомендуем данный инструмент тем, кто хорошо разбирается в IT и досконально знает все тонкости работы операционных систем Windows. Допущенные ошибки могут обойтись очень дорого.
⇡#SHADE Sandbox
Разработчик: SHADE Sandbox LLC.
Сайт продукта: shadesandbox.com.
Стоимость: от $30 (доступна 30-дневная пробная версия продукта).
Песочница, к созданию которой приложил руку наш соотечественник, выпускник государственного университета «Дубна», основатель компании SHADE Sandbox LLC Евгений Балабанов.
SHADE Sandbox имеет аскетичный интерфейс, а само управление программой построено по принципу Drag-and-drop — для включения того или иного приложения в защищённую среду достаточно перенести его ярлык в стартовое окно песочницы. Настроек как таковых практически нет: доступны только средства просмотра виртуальных директорий, выступающих в качестве связующего звена между хостовой ОС и изолированными средами, а также инструменты для быстрой очистки песочниц от файлового мусора. Поддерживается одновременная работа с несколькими защищёнными окружениями и интеграция с проводником Windows. Наличие аппаратной виртуализации для работы с SHADE Sandbox не обязательно, что допускает возможность использования программы на старых ПК.
Comodo Free Antivirus
Разработчик: Comodo Security Solutions.
Сайт продукта: antivirus.comodo.com.
Стоимость: бесплатно.
Антивирусное решение, важная составляющая которого (применительно к нашему обзору) — встроенная песочница. Обычно подобного рода инструменты предлагаются только в коммерческих продуктах, здесь же американская компания-разработчик Comodo Security Solutions сделала приятное исключение.
Comodo Free Antivirus поддерживает одновременную работу со множеством песочниц и позволяет управлять уровнем обеспечиваемой ими защиты. В частности, для изолированных сред можно открывать доступ к определённым файлам и папкам на компьютере, а также к буферу обмена, указанным ключам и значениям реестра Windows. Также допускается настройка автоматического запуска в песочнице приложений, требующих повышенных привилегий в системе либо имеющих низкий рейтинг согласно оценочной шкале антивируса и используемых им облачных аналитических сервисов. Предусмотрена парольная защита песочниц.
Для понимания «внутренней кухни» изолированных сред и просмотра функционирующих в них процессов имеется встроенный диспетчер задач. С его помощью можно анализировать поведение программ, просматривать рейтинг запускаемых ими процессов, блокировать выполнение отдельных исполняемых файлов и решать прочие административные задачи.
В целом Comodo Free Antivirus производит впечатление качественно сделанного продукта. Он бесплатен и при этом не раздражает пользователя навязчивыми рекламными баннерами как иные распространяемые на безвозмездной основе антивирусы. Единственное замечание: в процессе инсталляции программа норовит установить фирменный браузер Comodo Dragon Web Browser — тут необходимо быть внимательным.
Avast Premium Security
Разработчик: Avast Software.
Сайт продукта: avast.com/premium-security.
Стоимость: от $40/год (доступна 30-дневная пробная версия продукта).
Коммерческий антивирус со множеством защитных функций, в числе которых также фигурирует возможность создания безопасных сред. При этом устанавливать весь комплект входящих в Avast Premium Security модулей нет необходимости, можно ограничиться только песочницей — инсталлятор программы допускает такую возможность.
Набор предлагаемых песочницей Avast Premium Security функций довольно скромный: можно блокировать доступ «виртуализованных» приложений в интернет, разрешать перенос данных за пределы изолированного окружения и составлять список автоматически запускаемых в защищённой среде программ.
Для мониторинга запущенных в песочнице процессов предусмотрен простейший диспетчер задач.
Avast Software почти четверть века работает в сфере информационной безопасности, имеет хорошую репутацию, а поэтому в надёжности и практичности программных решений чешского разработчика можно не сомневаться. К сожалению, в свете последних геополитических событий компания приостановила продажу своих продуктов в России и Белоруссии, поэтому приобрести антивирус теперь можно только окольными путями. Скачивание дистрибутивов тоже заблокировано.
⇡#360 Total Security
Разработчик: Beijing Qihu Keji.
Сайт продукта: 360totalsecurity.com.
Стоимость: бесплатно.
Ещё один антивирус, поддерживающий работу с Sandbox-окружениями. Разработан в Китае и в бесплатной версии обвешан баннерами как новогодняя ёлка, — типичное явление едва ли не для всех программных продуктов из Поднебесной империи.
В отличие от упомянутых выше Comodo Free Antivirus и Avast Premium Security программный комплекс 360 Total Security требует поддержки виртуализации на аппаратном уровне — без неё песочница работать не будет. Этот важный момент почему-то не отмечен в прилагаемой к программе документации, но на него следует обращать внимание.
По набору функций песочница 360 Total Security во многом повторяет конкурирующие решения. Можно блокировать доступ в Сеть для изолированных приложений и управлять настройками хранения создаваемых в песочнице файлов. Доступен выбор программ для автоматического запуска в защищённой среде и простейший менеджер задач.
Помимо песочницы и собственно антивируса 360 Total Security несёт в себе ворох программных компонентов сомнительной ценности вроде анализатора дискового накопителя и оптимизатора ОС. Отказаться от этого балласта не представляется возможным, а зазря забивать диск компьютера ненужным софтом — довольно сомнительная затея, на наш взгляд. Видимо, китайские разработчики думают иначе.
⇡#Заключение
Ассортимент Sandbox-приложений для платформы Windows и индивидуальных пользователей нельзя назвать обширным — приходится выбирать из того, что есть. Из приведённых в обзоре песочниц смело можем рекомендовать Windows Sandbox, Microsoft Defender Application Guard и Comodo Free Antivirus (если не смущает «довесок» в виде антивируса). Avast Premium Security тоже неплох, но он платный, и есть трудности с его приобретением. Хорош во всех отношениях Sandboxie, но это продукт профессионального уровня, который может быть интересен скорее IT-гикам, нежели обычным пользователям, привыкшим, чтобы всё работало «из коробки».
Если Вы заметили ошибку — выделите ее мышью и нажмите CTRL+ENTER.
Содержание статьи
- Создаем Less Privileged App Container
- Пишем LPAC loader для любого приложения
- Проверка на изоляцию
- Заключение
Начиная с восьмой версии в Windows появился встроенный механизм контейнеров, которые позволяют изолировать процессы путем значительного усечения их прав. Этому системному механизму дали название Less Privileged App Container (LPAC), он поддерживается некоторыми приложениями, например браузером Chrome. В этой статье я покажу, как использовать его в своих программах.
Сендбокс-изоляция часто применяется в защитных приложениях, а также на ее основе строятся компоненты антивирусов, называемые HIPS (Host-based Intrusion Prevention System), и отдельные приложения для изолированных сред типа Sandboxie. Такие защитные механизмы реализованы через драйвер-фильтр режима ядра. Он сложен в написании и тестировании, имеет громадное количество шаблонного кода и должен перехватывать значительное количество функций NTAPI, чтобы менять их параметры на лету, таким образом создавая песочницу внутри файловой системы.
Существует более простой способ устроить изоляцию произвольных приложений. Инженеры Microsoft уже позаботились об этом и интегрировали интересный механизм в ядро Windows. Его суть заключается в том, что система жестко ограничивает доступ к устройствам (таким как микрофон, камера, GPS или модуль 4G), файлам в системе (иногда — даже для чтения) и процессам (ограничиваются межпроцессные взаимодействия). Также ограничения накладываются на работу с сетью (например, на открытие портов или сокетов), обращения к сетевому реестру и оконному интерфейсу других приложений.
Когда приложение запущено внутри LPAC, все разрешения ему требуется выдавать явно. Это весьма полезный механизм с точки зрения безопасности, если в приложении есть уязвимости, которые злоумышленник может использовать для повышения привилегий и доступа к другим ресурсам. Если уязвим, например, браузер, то такую атаку можно выполнить удаленно. Кроме того, когда запускаешь неизвестное приложение, неплохо было бы обезопасить себя от несанкционированных действий с его стороны, научившись запускать приложения в контейнере LPAC.
Создаем Less Privileged App Container
Прежде чем запускать приложение, нам нужно создать сам контейнер. В этом нам поможет функция WinAPI CreateAppContainerProfile. Вот ее прототип:
HRESULT WINAPI CreateAppContainerProfile( _In_ PCWSTR pszAppContainerName, _In_ PCWSTR pszDisplayName, _In_ PCWSTR pszDescription, _In_ PSID_AND_ATTRIBUTES pCapabilities, _In_ DWORD dwCapabilityCount, _Out_ PSID *ppSidAppContainerSid ); И сам код создания контейнера:
WCHAR sandbox_name[] = L"SandboxLPAC"; WCHAR sandbox_desc[] = L"My SandboxLPAC"; PSID sid = NULL; HRESULT status; result = CreateAppContainerProfile(sandbox_name, sandbox_name, sandbox_desc, NULL, 0, &sid); В случае ошибки неплохо было бы проверить, не создан ли наш контейнер ранее; если создан, то мы получим его SID. Вот прототип функции WinAPI, которая выясняет SID уже созданного контейнера:
HRESULT WINAPI DeriveAppContainerSidFromAppContainerName( _In_ PCWSTR pszAppContainerName, _Out_ PSID *ppsidAppContainerSid ); Далее код реализации проверки. Как видишь, он очень прост.
if (HRESULT_CODE(status) == ERROR_ALREADY_EXISTS) status = DeriveAppContainerSidFromAppContainerName(sandbox_name, &sid); Так или иначе мы получаем SID контейнера.
INFO
Security Identifier (SID) — идентификатор безопасности, структура данных в Windows, которая может идентифицировать системные объекты, например элементы управления доступом (Access Control Entries, ACE), токены доступа (Access Token), дескрипторы безопасности (Security Descriptor). SID всегда начинается с буквы S, далее идут числа, которые обозначают номер редакции ОС, источники выдачи, удостоверяющие центры и другую информацию.
Насколько просто обойти изоляцию LPAC?
- Теоретически можно, но готовых эксплоитов еще нет
- Ее научились обходить, правда пока только в Windows 8
- Ее научились обходить уже и в Windows 10
Загрузка …
Пишем LPAC loader для любого приложения
Итак, контейнер LPAC создан, SID получен. Теперь наша задача — заставить Windows запустить произвольное приложение в этом контейнере. Но сначала нам необходимо разобрать процесс запуска приложений и понять, как можно задавать определенные атрибуты запуска и какие системные структуры отвечают за это.
Для запуска приложений в Windows используется функция WinAPI CreateProcess с массой параметров, и именно эта функция имеет ключевое значение в нашей задаче. Давай посмотрим на ее прототип и разберем основные параметры.
BOOL WINAPI CreateProcess( _In_opt_ LPCTSTR lpApplicationName, _Inout_opt_ LPTSTR lpCommandLine, _In_opt_ LPSECURITY_ATTRIBUTES lpProcessAttributes, _In_opt_ LPSECURITY_ATTRIBUTES lpThreadAttributes, _In_ BOOL bInheritHandles, _In_ DWORD dwCreationFlags, _In_opt_ LPVOID lpEnvironment, _In_opt_ LPCTSTR lpCurrentDirectory, _In_ LPSTARTUPINFO lpStartupInfo, _Out_ LPPROCESS_INFORMATION lpProcessInformation ); Поле lpApplicationName — это путь к исполняемому файлу, который мы собираемся запускать. Далее идут поля lpCommandLine, lpProcessAttributes, lpThreadAttributes, bInheritHandles, которые сейчас не представляют для нас интереса. Можем им всем присвоить значение NULL (FALSE).
А вот на поле dwCreationFlags мы остановимся подробнее. Оно отвечает за флаги, которые устанавливают приоритет процесса и регламентируют его создание. Например, если в это поле передать значение CREATE_NO_WINDOW для консольного приложения, то оно запустится без создания консольного окна. А если передать значение CREATE_SUSPENDED, тогда процесс (основной поток) будет создан приостановленным (в состоянии ожидания пробуждения функцией ResumeThread). Нам же необходимо задать флаг EXTENDED_STARTUPINFO_PRESENT: он «разрешит» нам расширенные параметры запуска приложения.
Далее идет поле lpStartupInfo, которое имеет тип LPSTARTUPINFO. Это указатель на структуру STARTUPINFO, которая регламентирует параметры основного окна приложения или терминала, а также его дескриптор.
Важный момент. При передаче флага запуска EXTENDED_STARTUPINFO_PRESENT мы можем вместо стандартной структуры STARTUPINFO передать ее усовершенствованную версию — структуру STARTUPINFOEX. Она имеет вид:
typedef struct _STARTUPINFOEX { STARTUPINFO StartupInfo; PPROC_THREAD_ATTRIBUTE_LIST lpAttributeList; } STARTUPINFOEX, *LPSTARTUPINFOEX; Можно считать, что это стандартная структура STARTUPINFO (поле StartupInfo), дополненная списком атрибутов запуска (поле lpAttributeList). Эти атрибуты можно проинициализировать функцией WinAPI InitializeProcThreadAttributeList:
BOOL WINAPI InitializeProcThreadAttributeList( _Out_opt_ LPPROC_THREAD_ATTRIBUTE_LIST lpAttributeList, _In_ DWORD dwAttributeCount, _Reserved_ DWORD dwFlags, _Inout_ PSIZE_T lpSize ); А теперь добавляем их в список параметров функцией UpdateProcThreadAttribute:
BOOL WINAPI UpdateProcThreadAttribute( _Inout_ LPPROC_THREAD_ATTRIBUTE_LIST lpAttributeList, _In_ DWORD dwFlags, _In_ DWORD_PTR Attribute, _In_ PVOID lpValue, _In_ SIZE_T cbSize, _Out_opt_ PVOID lpPreviousValue, _In_opt_ PSIZE_T lpReturnSize ); Обрати внимание на поле PVOID lpValue, к нему мы еще вернемся. А теперь переходим к практике. Весь код манипуляций с атрибутами потоков выглядит таким образом:
SIZE_T size_of_attr = 0; STARTUPINFOEX ex_start_info = { 0 }; SECURITY_CAPABILITIES secap = { 0 }; InitializeProcThreadAttributeList(NULL, 1, NULL, &size_of_attr); ex_start_info.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)malloc(size_of_attr); InitializeProcThreadAttributeList(ex_start_info.lpAttributeList, 1, NULL, &size_of_attr); UpdateProcThreadAttribute(ex_start_info.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES, &secap, sizeof(secap), NULL, NULL); Первые три строки кода (если не считать объявление переменных) создают PROC_THREAD_ATTRIBUTE_LIST, то есть список параметров запуска. Вызов WinAPI UpdateProcThreadAttribute модифицирует его должным образом и создает нужную нам структуру STARTUPINFOEX ex_start_info, которую мы передадим функции CreateProcess. Четвертое поле этой функции, lpValue, получает на вход структуру secap, которая имеет тип SECURITY_CAPABILITIES и выглядит так:
typedef struct _SECURITY_CAPABILITIES { SID AppContainerSid; PSID_AND_ATTRIBUTES Capabilities; DWORD CapabilityCount; DWORD Reserved; } SECURITY_CAPABILITIES, *PSECURITY_CAPABILITIES; Чтобы «настроить» ее под свои нужды, заполняем поля перед вызовом UpdateProcThreadAttribute. Первое поле структуры — это AppContainerSid, в него мы передаем SID нашего контейнера LPAC. Второе поле — Capabilities, оно тоже является структурой:
typedef struct _SID_AND_ATTRIBUTES { PSID Sid; DWORD Attributes; } SID_AND_ATTRIBUTES, *PSID_AND_ATTRIBUTES; Третье поле (SECURITY_CAPABILITIES) называется CapabilityCount. Это счетчик параметров процесса, которыми мы его наделяем.
Давай посмотрим на код, который реализует все перечисленное выше и создает нам корректно заполненную структуру SECURITY_CAPABILITIES.
SID_AND_ATTRIBUTES sid_attr; DWORD sid_size = SECURITY_MAX_SID_SIZE; sid_attr = (SID_AND_ATTRIBUTES *)malloc(sizeof(SID_AND_ATTRIBUTES)); ZeroMemory(secap, sizeof(SECURITY_CAPABILITIES)); ZeroMemory(sid_attr, sizeof(SID_AND_ATTRIBUTES)); sid_attr.Sid = malloc(SECURITY_MAX_SID_SIZE); CreateWellKnownSid(capabili, NULL, sid_attr.Sid, &sid_size); sid_attr.Attributes = SE_GROUP_ENABLED; &secap->Capabilities = sid_attr; &secap->AppContainerSid = sid; Единственная сложность, которую ты можешь встретить в этом коде, заключается в неизвестной еще функции CreateWellKnownSid. Она создает SID для значений, которые были предопределены заранее. Самое интересное для нас — это ее первое поле, в котором через переменную capabili передается перечисление типа WELL_KNOWN_SID_TYPE, где на момент написания статьи содержится 94 пункта. Они наделяют наш SID различными правами. Ознакомиться с полным списком можно в MSDN по ссылке. Для собственных экспериментов можно выбрать любой по вкусу. ????
Итак, все основные системные структуры созданы, сам контейнер LPAC создан, осталось только запустить блокнот в контейнере. Зададим нужные параметры вызова и наши заранее подготовленные структуры.
PROCESS_INFORMATION pinfo = { 0 }; BOOL ok = CreateProcessA("c:\windows\notepad.exe", NULL, NULL, NULL, FALSE, EXTENDED_STARTUPINFO_PRESENT, NULL, NULL, (LPSTARTUPINFOA)&ex_start_info, &pinfo); Результат работы можно увидеть в программе ProcessExplorer: notepad.exe запустится внутри контейнера Less Privileged App Container.
Какое предустановленное приложение по умолчанию запускается в LPAC?
- Internet Explorer, начиная с Windows 8.1
- «Проводник» во всех версиях Windows 10
- MS Edge, начиная с версии Windows 10 1703
Загрузка …
Проверка на изоляцию
Как проверить, работает ли процесс в контейнере LPAC или нет, программным путем, без использования сторонних приложений? Достаточно получить хендл интересующего нас процесса. Если процесс сторонний, то нам поможет функция WinAPI OpenProcess, а для своего пригодится GetCurrentProcess. Далее открываем токен доступа процесса (Access token) и смотрим его TOKEN_INFORMATION_CLASS, который будет равен TokenIsAppContainer в том случае, если процесс работает внутри контейнера.
BOOL InLPAC(HANDLE h_proc) { HANDLE proc_token; DWORD len; BOOL lpac = 0; OpenProcessToken(h_proc, TOKEN_QUERY, &proc_token); if (!GetTokenInformation(proc_token, TokenIsAppContainer, &lpac, sizeof(lpac), &return_len)) return false; return lpac; } INFO
Маркер доступа (Access token) — объект Windows, содержащий привилегии учетной записи пользователя, от которого был запущен процесс. Помимо этого, Access token содержит информацию об ограничениях доступа к потоку, здесь же перечислены SID и списки привилегий процесса. Посмотреть структуру маркера доступа можно, введя в WinDbg команду dt_TOKEN.
На вход этой функции необходимо передать хендл интересующего нас процесса, и она вернет TRUE, если процесс работает внутри Less Privileged App Container, и FALSE, если процесс выполняется вне его.
С какими новыми методами защиты совместно работает LPAC?
- No Child Proc и Protected Processes
- Win32k Syscall Filtering, SEHOP и ASLR
- LPAC работает независимо от других компонентов
Загрузка …
Заключение
Мы разобрали Less Privileged App Container, встроенную реализацию изолированной среды в Windows. Чтобы раскрыть тему, нам пришлось детально рассмотреть процесс запуска приложений в Windows средствами WinAPI CreateProcess, а также узнать о нескольких важных системных структурах, без которых ничего бы не получилось. Я надеюсь, что эта статья поможет тебе в исследовании системных механизмов Windows.
Источник
We are thrilled to announce the public preview launch of Win32 app isolation. This blog post provides an overview of the topic. To learn more about the developer experience and engage with the team, please visit our GitHub page.
It is worth noting that Win32 app isolation is an addition to the family of existing Windows sandbox options, such as Windows Sandbox and Microsoft Defender Application Guard. While these options are based on virtualization based security, Win32 app isolation is built on the foundation of AppContainers (and more). AppContainers are specifically designed to encapsulate and restrict the execution of processes, helping to ensure they operate with limited privileges, commonly referred to as low integrity levels.
Win32 App isolation
The frequency and impact of zero-day vulnerabilities have witnessed a substantial increase over the years. Attackers frequently focus their attention on popular applications, exploiting either unknown or unpatched vulnerabilities. That’s why we strongly advocate for the integration of preventive and containment measures.
To this end, we propose using the combined power of Win32 app isolation and cutting-edge technologies like Smart App Control, which together work to effectively block untrusted applications and limit damage if trusted apps are compromised. By implementing this approach, a robust security strategy can be established, significantly mitigating the potential harm caused by zero-day attacks.
Win32 app isolation is a new security feature designed to be the default isolation standard on Windows clients. It is built on AppContainers and offers several added security features to help windows platform defend against attacks that leverage vulnerabilities in the application (this could be 3P libraries as well). To isolate their apps, application developers can update their applications using the tools provided by Microsoft. For more information on Win32 app Isolation developer experience, please visit our GitHub page.
Figure 1: Combining Preventive and Containment Strategies.
Another benefit of isolation is to safeguard end-user privacy choices in the event of a breach. When a Win32 app runs with the same privilege as the user, it is possible to allow itself access to user’s information without the user’s consent. Consequently, there is a risk of unauthorized access to the user’s privacy data by malicious actors without their knowledge or consent.
Goals of Win32 app isolation
Figure 2: Key objectives of Win32 app isolation
Limit damage: Win32 app isolation achieves its goal of limiting impact (in the event apps are compromised) by running apps with low privilege, which requires a multi-step attack to break out of the container. Attackers must target a specific capability or vulnerability, compared to having broad access and since the attack must be directed at a specific vulnerability, mitigation patches can be quickly applied, reducing the shelf life of the attack.
Reduce developer effort: To reduce the effort required for developers to update their apps, Microsoft provides developer tools and experiences, with a focus on the MSIX packaging tool and the Application Capability Profiler.
Seamless user experience: Finally, while the focus is on security, it is critical that security decisions are not delegated to end-users via cryptic security prompts, and application compatibility is maintained.
Limit damage
The protection offered by Win32 App isolation follows a two-step process. In the first step, the Win32 application is launched as a low integrity process using AppContainer, which is recognized as a security boundary by Microsoft. Consequently, the process is limited to a specific set of Windows APIs by default and is unable to inject code into any process operating at a higher integrity level.
In the second step, the least privilege is enforced by granting authorized access to Windows securable objects. This access is determined by capabilities that are added to the application manifest through MSIX packaging. Securable objects in this context refer to Windows resources whose access is safeguarded by capabilities. These capabilities serve as a means to implement a Discretionary Access Control List on Windows.
Reduce developer effort
To help ensure that isolated applications run smoothly, developers must define the access requirements for the application via access capability declarations in the application package manifest.
The Application Capability Profiler (ACP) simplifies the entire process by allowing the application to run in “learn-mode” with low privileges. Instead of failing access if the capability is not present, ACP allows access and logs additional capabilities required for access if the application were to run isolated.
Figure 3: Overview of Application Capability Profiler
Under the hood, ACP uses the Windows Performance Analyzer data layer backend (WPA) and parses Event Trace Logs (ETL) to provide a list of additional capabilities needed. ETLs are detailed and verbose, and ACP parses them to output missing capabilities as a file. Once the capabilities are output, they can simply be included in the application package manifest.
Finally, ACP provides a WPA profile file “ACP-StackTrace.wpaProfile” that allows the user to easily configure WPA to inspect the event trace logs captured (in learn-mode) for relevant call stack information. In most cases, call stack analysis using WPA is not required.
For more information on ACP, please refer to the Github documentation page, linked here.
Seamless user experience
To create a smooth user experience that aligns with non-isolated/native Win32 applications, two key factors should be taken into consideration, as outlined below. The first factor relates to implementing methods to manage access to files and privacy information within and outside the isolation boundary (AppContainer). The second factor involves integrating Win32 apps with other Windows interfaces in a way that helps enable seamless functionality without causing perplexing user consent prompts. Now, let’s explore these factors in greater detail:
- Approaches for accessing data and privacy information;
- Integrating Win32 Apps for compatibility with other Windows interfaces;
Approaches for accessing data and privacy information.
Access to a user’s private data, such as camera, microphone, location, images, files, or folders, is not permitted without the user’s permission. However, the app may require access to certain program files, such as .NET libraries or protected registry keys. Asking for permission to access user folders is intuitive, but asking for permission to access program files and registry keys can be confusing for users. This confusion can be exploited by a compromised Win32 app to trick the user into allowing access to a registry key or sensitive file, which can then be used to escape the sandbox.
Figure 4: Effectively managing user consents.
To help prevent unauthorized access, several instrumentations have been built. Win32 apps need to explicitly include the “isolatedWin32-promptForAccess” capability and declare their intent to support prompting. Apps that do not require access to user’s data outside the app can opt out of any kind of user prompting for consent. Note, this capability only allows control over filesystem access, access to privacy related information such as camera, location and microphone shall always prompt.
Let us now discuss approaches on how user consents are obtained. User prompts are displayed when user consent is required, and the context of the prompt should be meaningful to the end user, such as accessing the user’s documents or camera. The other way to grant consent to files is via user selection such as when the user selects a file via the file dialog or by right clicking the context menu.
When the user grants consent to a specific file for the isolated application, the isolated application interfaces with Windows Brokering File System (BFS) and grants access to the files via a mini filter driver. BFS simply opens the file and serves as the interface between the isolated application and BFS.
File and registry virtualization helps ensure that apps continue to work while not updating the base file or registry. This also minimizes any user experience friction while maintaining application compatibility. Protected namespaces are created to allow access only to the app and do not require user consent. For example, access to a folder that has a property only known to the Win32 app and required for app compatibility can be granted.
Integrations with Win32 app isolation for compatibility
Figure 5: Maintaining app compatibility with isolation.
In order to achieve a high level of similarity and feature parity between isolated and non-isolated Win32 applications, certain allowances have been made. Specifically, Win32 apps operating with low privileges (referred to as low integrity level) are permitted to interact with file systems and various APIs. For example, interactions involving File Type Associations, including the “open with” option, COM servers, and file drag and drop, are facilitated through BFS (File System Broker).
Furthermore, capabilities included in the application manifest enable interactions with other Windows components, such as shell notifications and system tray icons. This ensures that these functionalities can be utilized without compromising the security of these applications.
What’s Next!
To summarize, Win32 app isolation enhances security for Windows clients by using AppContainer and additional security controls (as described above) to help reduce the risk of damage from compromised applications and help safeguard user privacy. The approach enforces least privilege through added capabilities and employs various strategies to help prevent unauthorized access, while minimizing developer effort and maintaining application compatibility.
To learn more about isolating your existing or new Win32 Apps, visit the GitHub page at: microsoft/win32-app-isolation (github.com). Win32 App Isolation is currently available for public preview. We look forward to your participation!
В эпоху развития облачных и мобильных технологий приложения задают ритм для инноваций. Контейнеры и связанная с ними экосистема позволяют создавать сервисы нового поколения. До недавнего времени контейнеры были вещью из мира Linux. Но с выходом Windows Server 2016 ситуация изменилась — технологии контейнеризации стремительно ворвались в мир Windows.
Согласно «Википедии», контейнеризация — это система виртуализации на уровне ОС, позволяющая создавать несколько изолированных экземпляров операционной системы на одном узле. Каждый контейнер, в отличие от виртуальной машины, имеет собственное пространство процессов и сетевой стек, но при этом все контейнеры в рамках хоста используют один и тот же экземпляр ядра операционной системы.
По сути, контейнер — это изолированная среда, где приложение может работать, не оказывая воздействия на остальную систему и не подвергаясь при этом воздействию с ее стороны. Контейнеры — это альтернатива привычной виртуализации, когда для создания изолированной среды не требуется эмулировать виртуальное оборудование. Контейнеры создаются за секунды, в отличие от минут для виртуальной машины, поэтому они нашли широкое применение в веб-сервисах с широкими границами масштабируемости.
Контейнеры как технология существуют еще с 80-х годов, то есть они возникли еще до привычных нам виртуальных машин. В 2000-е появились первые коммерческие продукты для организации контейнеров на Linux и Unix (Virtuozzo, HP-UX Containers), а в 2008 году появилась нативная поддержка контейнеризации в ядре Linux (LXC).
В последние годы контейнеры обрели новую популярность с появлением таких продуктов, как Docker и Apache Mesos, которые сделали работу с контейнерами проще, удобнее, расширили границы масштабируемости систем, а также позволили шире применять контейнеры в Enterprise-системах за счёт мощных возможностей управления.
Год назад компания Microsoft сделала первый серьёзный шаг в мир контейнеров, запустив Azure Container Service — облачный сервис контейнеризации на базе Docker Swarm и DC/OS (Apache Mesos). Этот сервис позволяет тысячам заказчиков по всему миру эффективно развёртывать масштабные решения с использованием контейнеров популярных форматов Docker и Mesos на базе ОС Linux.
Концепция контейнеров долгое время оставалась вещью из мира Linux (ну или Unix). Многие разработчики, пишущие на .NET или под SQL Server, кусали локти и завидовали своим коллегам по цеху из мира Linux, которые могли эффективно использовать контейнеры для целей Dev/Test, а потом так же быстро и эффективно переносить контейнеры в продуктивную среду. Windows Server 2016 меняет эту парадигму: теперь контейнеры доступны и для мира Windows, причём сразу в двух лицах — в виде контейнеров Windows Server и в виде контейнеров Hyper-V. Причём Windows Server для контейнеризации использует одну из самых популярных систем в индустрии — Docker.
Кстати, Microsoft идёт по пути скрещивания этих двух по сути параллельных продуктов — Azure Container Service и Windows Server Containers (и да, прошу их не путать). В данный момент идёт раннее тестирование Windows Server Containers в Azure Container Service, записаться можно вот здесь. Так что в будущем Azure Container Service сможет работать не только с контейнерами Linux, но и с контейнерами на базе Windows Server.
Типы контейнеров Windows
Контейнеры в Windows Server 2016 создаются из специальных шаблонов в формате Docker. Вы можете создавать свои шаблоны или воспользоваться богатым выбором из библиотеки Docker Hub. Подключение к контейнеру производится через командную строку, так как собственной графической оболочки контейнер не имеет. Контейнер не нужно патчить или обслуживать — вы просто создаёте новый шаблон контейнера и разворачиваете из него новые контейнеры вместо старого за секунды.
Контейнеры в Windows Server 2016 делятся на два типа:
Контейнеры Windows Server — обеспечивают изоляцию приложений благодаря изоляции процессов и пространств имен. Контейнер Windows Server использует одно ядро ОС совместно с хостом, на котором он работает, и всеми остальными контейнерами на этом узле.
Контейнеры Hyper-V — открывают более широкие возможности изоляции по сравнению с контейнерами Windows Server, так как каждый контейнер запускается в виртуальной машине со специальной легковесной версией ОС. В этой конфигурации каждый контейнер использует свою копию ядра, изолированную от других контейнеров, но при этом он обладает характеристиками обычного контейнера (быстрое развёртывание, использование библиотеки шаблонов Docker, stateless, мощные возможности по управлению).
Принципы работы контейнера Windows
Когда вы начнете использовать контейнеры, то заметите, что они во многом похожи на виртуальные машины. Контейнер работает под управлением операционной системы и содержит файловую систему, к нему можно получить сетевой доступ, что напоминает физический или виртуальный компьютер. При этом у контейнеров и виртуальных машин совершенно разные технология и принцип работы.
При создании контейнеров Windows и последующей работе с ними пригодятся перечисленные ниже основные понятия.
Узел контейнера. Физический или виртуальный компьютер под управлением Windows Server 2016, настроенный для работы с контейнерами Windows. На хосте работают один или несколько контейнеров Windows.
Образ контейнера. По мере того как в файловую систему или реестр контейнера вносятся изменения (например, при установке программного обеспечения), они регистрируются в «песочнице». Во многих случаях может потребоваться зарегистрировать это состояние, чтобы применить внесенные изменения при создании новых контейнеров. В этом и заключается суть образа: после остановки работы контейнера можно либо отключить «песочницу», либо преобразовать ее в новый образ контейнера. Предположим, вы развернули контейнер в образе Windows Server Core. Затем вы устанавливаете в этот контейнер MySQL. Создание нового образа на базе этого контейнера будет происходить аналогично его развертыванию. Этот образ будет содержать только внесенные изменения (MySQL) и при этом работать в виде слоя поверх образа ОС контейнера.
«Песочница». После запуска контейнера все операции записи (изменения файловой системы и реестра либо установка программного обеспечения) регистрируются на уровне «песочницы».
Образ ОС контейнера. Контейнеры развертываются из образов. Образ ОС контейнера — это первый из возможного множества слоев образа, составляющих контейнер. Этот образ представляет собой среду операционной системы. Образ ОС контейнера постоянный, его невозможно изменить.
Репозиторий контейнера. При каждом создании образа контейнера этот образ и его зависимости сохраняются в локальном репозитории. Эти образы можно использовать повторно много раз на узле контейнера. Образы контейнеров также можно хранить в открытом или закрытом реестре (например, Docker Hub), чтобы использовать на многих других узлах контейнеров.
Использование контейнеров Windows
Образ Docker можно создать где угодно, начиная с компьютера разработчика и заканчивая тестовыми и рабочими компьютерами. К тому же его развертывание в любой среде будет выполнено одинаково и за считанные секунды. Благодаря этому появилась развитая и расширяющаяся экосистема приложений, запакованных в контейнеры Docker. При этом в общедоступных репозиториях Docker Hub открытого реестра контейнерных приложений, который Docker обслуживает, в настоящее время опубликовано более 180 000 приложений.
Когда вы упаковываете приложение, образ содержит только само приложение и компоненты, необходимые для его запуска. При необходимости на базе этого образа создаются контейнеры. Кроме того, образ можно создать на основе другого образа, что еще более ускоряет рабочий процесс. Один и тот же образ могут использовать несколько контейнеров, что ускорит их запуск и снизит количество необходимых для этого ресурсов. Например, с помощью контейнеров можно выполнить развертывание микросервисов для распределенных приложений, а также отдельное быстрое масштабирование каждого сервиса.
Так как контейнер содержит все необходимое для запуска приложения, он отличается высокой переносимостью и может запускаться на любом компьютере под управлением Windows Server 2016. Можно создать и протестировать контейнер локально, а затем развернуть его образ на сервере поставщика услуг, а также в частном или общедоступном облаке компании. Адаптивность контейнеров позволяет использовать современные модели разработки приложений в крупномасштабных виртуализированных и облачных средах.
Контейнеры позволяют масштабировать веб-сервисы эффективнее, так как новые экземпляры стартуют в разы быстрее, чем виртуальные машины (плюс виртуальной машине, в отличие от контейнера, еще нужно время на provisioning).
Также контейнеры значительно менее требовательны к оперативной памяти, нежели виртуальные машины.
С помощью контейнеров разработчики могут создать приложение на любом языке. Такие полностью переносимые приложения можно запускать где угодно (на ноутбуке, настольном компьютере, сервере, в частном или публичном облаке) без необходимости изменения кода.
Если вам интересна тема контейнеров в Windows Server 2016, рекомендуем прочитать официальную документацию, статью Марка Руссиновича и посмотреть доклад по теме с конференции Microsoft Ignite.