Виртуальная машина для проверки вирусов
Может ли запущенный в виртуальной машине вирус проникнуть на хостовую систему
П оистине, достоин памятника тот разработчик, которому первому в голову пришла мысль о создании виртуальной машины как изолированной среды, в которой как в ограждённом загоне можно запускать программное обеспечение и даже эмулировать «чужеродные» архитектуры. К самым древним и как ни странно к самым надёжным в плане безопасности относятся виртуальные машины с так называемой полной эмуляцией, например, эмулятор Bochs, выпущенный в далёком 1994 году.
С тех пор, правда, много чего изменилось. Развился и сам Bochs, появились также гипервизоры, динамические виртуальные машины, среди которых особую популярность приобрели всем известные VirtualBox и VMware. Сегодня основной областью применения виртуальных машин является запуск и тестирование различного программного обеспечения, причём рядовые юзеры услугами эмуляторов пользуются даже чаще, чем разработчики.
В том же любимом всеми VirtualBox, к примеру, можно устанавливать операционные системы, а в них в свою очередь инсталлировать программы, игры, изменять параметры, применять твики и проделывать прочие трюки, не опасаясь за стабильность и работоспособность хостовой операционной системы. Некоторые идут ещё дальше, пробуя запускать на виртуальных машинах потенциально опасное или явно вредоносное программное обеспечения. Только вот насколько безопаснымм являются такие эксперименты и какова вероятность, что хитрый вирус, вырвавшись за пределы виртуальной машины, сможет нанести вред реальной операционной системе?
Увы, однозначного ответа на этот вопрос не существует, тем не менее, с большей долей вероятности можно утверждать, что запущенный на гостевой системе вирус, будь он хоть трижды зловредным, сделав своё чёрное дело, в её пределах и останется. Но для этого нужно соблюдать правила игры, иначе и до беды недалеко. Виртуальная машина, на которой предполагается запускать вирусы, должна быть максимально изолирована от основной системы. Максимально — значит не иметь с ней никаких связей насколько это возможно. Ни общих папок, ни дополнений гостевой ОС, ни расшаренных ресурсов, ни подключённых к компьютеру переносных носителей, кстати, прекрасно определяемых некоторыми типами эмуляторов, ни даже доступа к интернету.
Конечно, такие меры предосторожности делают обмен данными между виртуальной и хостовой машиной менее удобным, но в данном примере обеспечение безопасности является более приоритетной задачей. Впрочем, всем вышесказанным проблема не исчерпывается. Не стоит забывать о руткитах, уже давно научившихся распознавать виртуальные машины. Запускаясь в виртуальной среде, руткит ничем не выдаёт себя, а тестировщик, убеждённый в безопасности анализируемого ПО, запускает его на реальной системе, в результате чего последняя оказывается заражённой.
Так как же быть? Единственно верное решение – приобрести недорогой компьютер и проводить сомнительные эксперименты на нём, и если не деньги, то уж нервы себе точно сэкономите. В крайнем случае для запуска потенциально опасного ПО следует использовать виртуальные машины с полной эмуляцией, такие как Bochs, которые хоть и не обладают стопроцентной защитой от руткитов, но всё равно в плане безопасности на порядок превосходят VMware, VirtualBox, Virtual PC, мелких уязвимостей в которых хватало и будет хватать всегда.
Очень сложный выбор: 3 способа защитить виртуальную машину
Защищать или не защищать виртуальные среды от зловредов – вопрос давно и без особой дискуссии закрытый в пользу первого варианта. Другое дело – как защищать? Концепцию безагентового антивируса для платформы VMware мы разработали уже достаточно давно: подробнее о ней можно прочитать в этом посте Евгения Касперского. Но технологии на месте не стоят. Виртуализация привлекает новые прикладные IT-направления, а с ростом её применимости расширяются и специфические требования к защите. Очевидно, что для виртуального десктопа нужно одно, для базы данных – второе, веб-сайтам – третье и так далее. При этом безагентовый антивирус – далеко не единственный вариант защиты, а VMware – хотя и самая популярная, но не единственная платформа виртуализации.
Какие есть альтернативы и какая чему больше подходит?
Agentless (безагентовая) концепция.
Здесь будет «краткое содержание предыдущей серии», поскольку по этому вопросу уже есть исчерпывающий материал (см. ссылку выше).
В виртуальной инфраструктуре выделяется специальная машина, на которую устанавливается антивирусный движок. Его связь с остальными виртуалками и проверяемыми объектами обеспечивает нативная технология VMware vShield. Кроме того, vShield общается с системой управления антивируса для настройки, применения политик, включения/отключения защиты, оптимизации нагрузки и т.д.
Звучит как панацея, но у этой концепции есть недостаток фича. Это ограниченный антивирусный функционал – по сути, интерфейс vShield допускает только файловый сканер. Никаких продвинутых технологий вроде контроля над приложениями, защиты от эксплойтов, System Watcher, «белых списков», device и web control. Да и сканирование тоже в ограниченном виде – без карантина подозрительных объектов, без работы с памятью и процессами.
Это именно фичи, т.к., по всей видимости, в VMware и не собирались давать полноценный интерфейс для всех защитных функций. В принципе, у такого подхода тоже есть применение, но об этом ниже.
А сейчас посмотрим на следующую концепцию – Light Agent («Лёгкий агент»).
В этом варианте вместо vShield с антивирусным движком взаимодействует лёгкий агент, который устанавливается на каждую защищаемую виртуалку. Так мы снимаем ограничения интерфейса VMware для использования всего оборонного потенциала. И при этом сохраняем преимущества безагентного подхода – умеренный аппетит к ресурсам, управляемость, стойкость к «штормам» (деградация производительности кластера из-за одновременного обновления или проверки сразу многих машин).
Да, несмотря на название, лёгкий агент будет «потяжелее» безагентного решения – ему требуется и память в каждой виртуалке, и ресурсы процессора, и новые образы машин с предустановленным агентом. С другой стороны, при сегодняшних мощностях это весьма скромные аппетиты, особенно при условии, что в некоторых стандартных операциях он работает даже быстрее. А с учётом роста качества защиты и вовсе становится ясно, что овчинка выделки стоит.
А теперь – к практике. Недавно мы выпустили третью версию нашего продукта для виртуальных сред, реализовав в нем обе концепции защиты (Agentless и Light Agent). Помимо VMware мы теперь поддерживаем Citrix XenServer и Microsoft Hyper-V. К уже имеющемуся безагентовому решению для VMware добавился вариант защиты с использованием лёгкого агента для всех трёх платформ. При этом все продукты управляются из единой консоли, что особо важно для мульти-гипервизорных сред, чтобы не создавать консольный зоопарк.
Так каким задачам, какой вариант больше всего подходит?
В общем случае логика выбора защиты такая: для максимальной защиты гостевой Windows нужен лёгкий агент, на других ОС (Linux, OS X) – продукт для эндпоинтов. Увы, во втором варианте применение ограничено из-за соображений производительности и взаимодействия антивируса с фичами самой виртуальной среды. Над поддержкой других ОС лёгким агентом мы работаем. А если критична производительность, при этом ценность и разнообразие данных невысока и к ним ограничен доступ извне – тогда подходит безагентовое решение.
Мы проанализировали типовые прикладные задачи с использованием виртуализации и составили вот такую любопытную табличку.
Это не исчерпывающая и не однозначная картина — в разных организациях условия могут меняться, а список задач расширяться. Её цель – показать модель угроз и методологию оценки задач и приоритетов.
Возвращаемся к заголовку. Ну, что, выбор-то, получается, совсем даже и не сложный!
Вирусы и руткиты в виртуальной машине
Виртуальная машина, на которой предполагается запускать вирусы, должна быть максимально изолирована от основной системы. Максимально — значит не иметь с ней никаких связей насколько это возможно. Ни общих папок, ни дополнений гостевой ОС, ни расшаренных ресурсов, ни подключённых к компьютеру переносных носителей, кстати, прекрасно определяемых некоторыми типами эмуляторов, ни даже доступа к интернету.
Не стоит забывать о руткитах, уже давно научившихся распознавать виртуальные машины.
В крайнем случае для запуска потенциально опасного ПО следует использовать виртуальные машины с полной эмуляцией, такие как Bochs, которые хоть и не обладают стопроцентной защитой от руткитов, но всё равно в плане безопасности на порядок превосходят VMware, VirtualBox, Virtual PC, мелких уязвимостей в которых хватало и будет хватать всегда.
4 ответа 4
Следует различать следующие сценарии выхода вируса из виртуалки:
он может атаковать хост-систему через виртуальную сеть как обычный сетевой червь;
вирус может воспользоваться эксплоитом для конкретной модели VM;
вирус может воспользоваться эксплоитом для процессора.
Так вот, по первому вашему вопросу. Атака вида 1 успешно предотвращается отключенными галочками. Атаки вида 3 отключенными галочками в общем случае не предотвращаются.
Однако, есть мнение что установка гостевых дополнений делает атаку 3 возможнее просто из-за увеличения количества компонентов и их сложности. Особенно сложными являются технологии виртуализации видеокарты. В частности, ранее найденные и сейчас закрытые уязвимости VirtualBox класса RCE относились именно к этой технологии.
Теперь о том сколько виртуальных машин может обойти руткит. Тут все просто: обойдя виртуальную машину, толковый руткит заражает систему одним уровнем выше, после чего начинает работать на ней. И начав работать, он опять делает попытку заразить те системы до которых дотянется.
Список известных «мелких уязвимостей» можно найти поискав в интернете «(имя продукта) CVE».
Обновление На процессорах Intel нашли уязвимость Meltdown, которая, в случае отсутствия закрывающих ее патчей, позволяет любому процессу произвольно читать любые места в оперативной памяти. Поэтому лучше не работайте с важными данными при запущенной виртуалке с вирусами если у вас Intel.
Установка и настройка виртуальной машины VirtualBox для проверки программ и вирусов
Всем большой привет! Сегодня речь пойдет о Виртуалке. Да не о Наташке-виртуалке, та что сидит в вконтакте, а о виртуальной машине.
Давным-давно, в одной из моих предыдущих статей, а точнее в статье «Где скачать вирусы», я обещал рассказать о том, как установить и правильно настроить виртуальную машину Virtualbox для тестирования программ, проверки их на склейку и анализа вирусов.
С тех пор прошло много времени, и на днях, когда меня окончательно доела совесть, я наконец-то решил выполнить обещанное. Эта статья будет первой частью мануала. В ней речь пойдет о правильной настройке виртуальной машины, а в следующей статье — об анализе вредоносных программ. Ну что, друзья, погнали!
Виртуалка
Виртуальная машина (VM — Virtual machine) или в простонародье виртуалка — программная и/или аппаратная система, эмулирующая аппаратное обеспечение некоторой платформы (target — целевая, или гостевая платформа) и исполняющая программы для target-платформы на host-платформе (host — хост-платформа, платформа-хозяин). Более глубокие теоретические знания вы можете почерпнуть на Wikipedia.
Зачем нужна виртуальная машина?
Виртуализация позволяет создавать операционную систему в операционной системе и тестировать программы не устанавливая их на основную машину. Также виртуализация позволяет заниматься пентестом. Вместо того чтобы взламывать чужие компьютеры (что как вы знаете считается незаконным и наказуемым) находить или использовать уязвимости для взлома операционных систем и другого софта у себя дома. Подробнее о том как правильно настроить сеть на виртуальной машины для пентеста, я расскажу позже в отдельной статье.
Друзья мои, если вы хотите быть немного больше чем просто пользователь компьютера, вы должны уметь пользоваться виртуальной машиной и делать это правильно.
Какой виртуальной машиной пользуется автор?
Меня часто спрашивали, как я проверяю программы. Для тестирования белого софта я использую виртуальные машины VirtualBox и VMware Workstation. Для серого софта я не использую виртуальные машины, для этого у меня выделен отдельный компьютер — карантин, которой был собран специально для этой цели. Сделал я это по двум причинам:
Какая виртуальная машина лучше?
Это спорный вопрос. Под него у нас отведена отдельная статья «Обзор виртуальных машин«. Почитайте на досуге, там же в начале статьи на фотке вы найдете другана сегодняшней зачетной тел#чки.
Виртуальная машина VirtualBox
Походив по ссылкам, выше вы уже поняли, что существует большое количество виртуалок. Напрашивается вопрос: «почему именно Виртуал Бокс?» — ведь он не самый лучший. Да, не самый, но зато бесплатный и уже родной. Поэтому в этой инструкции будет про установку VirtualBox.
Скачать VirtualBox
Скачивать Virtualbox надо только с сайта разработчиков, не с трекеров и не софт-порталов. Скачанный с торрент-трекеров ВиртуалБокс может быть склеен с вредоносом. А на софт-порталах версия может быть устаревшая, да еще и со всякими уязвимостями. С помощью которых малварь, т.е. вредонос, может выбежать из гостевой машины и немного вас покусать о_0.
Скачать VirtualBox вы можете бесплатно на официальном сайте по этой ссылке. В бесплатной загрузке доступны версии для операционных систем:
Исходя из того какая у вас операционная система. В этой статье я буду устанавливать VirtualBox на Windows 10. Установка VirtualBox на все версии Windows идентична.
Переходим на официальный сайт и скачиваем установочный файл.
Файл весит примерно 120мб, после установки занимает на диске 150мб (не считая установленных виртуальных машин).
Установка VirtualBox
Итак, после того как мы скачали последнюю версию Виртуал Бокс приступим к установке. Запускаем программу и нажимаем «Next». После чего появится окно выбора компонентов. Нечего не меняя нажимаем «Next».
В следующем окне нечего не меня еще раз жмем «Next».
Теперь появится окно, которое говорит о том, что во время установки программы временно будет отключен интернет. Нажимаем «Yes».
Еще раз «Next». И в конце «Finish». На этом утомительный процесс установки завершен.
Настройка VirtualBox
Теперь перейдем к настройке виртуалки и установке операционной системы.
Если у вас в системе установлен русский язык, программа автоматически при первом запуске поменяет язык интерфейса на русский. Если это не произошло, то зайдите в меню «Файл» —> «Настройки» и на вкладке языки выберите ваш язык.
В принципе в настройках самого Виртуал Бокс больше нечего менять не надо, но если вы в теме и знаете что делаете, можете там маленько побродить.
Создание виртуальной машины
Нажимаем кнопку «Создать».
В окне настроек указываем имя (в будущем можно изменить), тип и версию операционной системы. Имейте ввиду, чем старее версия Windows, тем меньше ресурсов необходимо выделять. Я устанавливаю Windows 10, а как вы знаете она довольно требовательна к ресурсам. Microsoft утверждает, что минимальные требования Windows 10 для полноценной работы: 1гб для 32-битной и 2гб для 64-битной, но это фигня. На таких настройках вы не сможете тестировать никакие программы, единственное что сможете — это заняться мазохизмом.
Поэтому выставляем максимально возможный объем виртуальной памяти. У меня 32гб, и я обычно выделяю 8гб для виртуальной машины. Иногда даже больше, все зависит от задач и от того сколько виртуальных машин запускаю одновременно.
В конце жмем кнопку «Создать» и переходим к созданию виртуального жесткого диска. Минимальный размер жесткого диска для Windows 10: 16гб для 32-битной версии и 20гб для 64-битной. Ставим минимум 80гб и отмечаем галочкой чекбокс «Динамический размер».
Также можно изменить месторасположения виртуальной машины. Если есть возможность, то в плане быстродействия лучше установить на SSD-диск. Обычно это диск C.
Все хорошенько проверяем и нажимаем кнопочку «Создать».
Настройка виртуальной машины
Теперь правым кликом мышки на созданной виртуальной машине открываем настройки. В меню «Общие» переходим на вкладку «Дополнительно» и отключаем использование общего буфера обмена и функцию Drag’nDrop.
В меню «Система» переходим на вкладку «Процессор» и задаем количество процессоров виртуальной машины. У меня 4, поэтому я выставил 2цп. Если у вас 2, выставляете 1цп. И ползунок загрузки процессора на максимум.
В том же меню переходим на вкладу «Ускорение» и отмечаем галочками все чекбоксы.
В меню «Сеть» отключаем сетевой адаптер. Но в некоторых ситуациях, имея дело с вирусами, может потребоваться включение адаптера. Если будете включать, то отключайте интернет, выбрав в выпадающем меню тип подключения «Не подключен». А если захотите интернет, настройте отдельную сеть, не используя Nat-подключение. Последнее для параноиков.
В меню «USB» убираем галочку с чекбокса «Включить контролер USB».
В меню «Общие папки» добавим папку, куда и будем скидывать для нашей виртуальной машины нужные программы. Нажимаем на значок с права и появившемся окне настраиваем общую папку. Выберите путь, где будет находится общая папка, и обязательно поставьте галочки как показано на скрине ниже. В особенности на чекбоксе «Только для чтения».
Если вы будете использовать виртуальную машину для другой цели, например для тестирования операционных систем, то в таком случае можете пропустить этот чекбокс. Но если вы создаете виртуальную машину для проверки подозрительных программ и вирусов, то конечно же следует включить функцию «Только для чтения».
Установка Windows на виртуальную машину VirtualBox
В главном окне программы отмечаем нашу виртуальной машину и нажимаем на зеленую кнопку «Запустить». Запустится виртуальная машина и тут же выдаст ошибку. Это нормально, для установки операционной системы надо подгрузить образ диска. Для этого в выпадающем меню «Устройства» —> «Оптические диски» нажмем «Выбрать образ диска».
Все, теперь необходимо следовать этапам установки ОС.
Дополнения гостевой ОС
После завершения процесса установки операционной системы необходимо установить дополнения гостевой ОС. Для этого в выпадающем меню «Устройства» нажмем на пункт «Подключить образ диска Дополнений гостевой ОС». Посмотрите на скрин выше.
После чего следуем этапам установки. Нечего там сложного нет, просто где нужно жмете «Next», а затем перегружаете виртуальную машину.
Помимо этого после установки Windows, в самой операционной системе обязательно включите отображение скрытых файлов. На рабочем столе будут маячить файлы desktop.ini, но нечего не поделаешь, так надо, смеритесь с этим.
Теперь на чистую Windows нужно установить все необходимые программы и утилиты. Для работы с реестром можете установить утилиту Regshot, о которой мы подробно рассказывали в статье «Как отследить изменения реестра». Обо всех других инструментах для анализа программ и вирусов я расскажу позже в отдельной статье.
Если вы не желаете ждать и хотите приступить к работе прямо сейчас, вот еще одна вещь которую необходимо сделать. Пока Windows чистая надо сделать снимок состояния или клонировать операционную систему.
Снимки VirtualBox
Снимки ВиртуалБокс позволяют в один клик откатить операционную систему к прежнему состоянию. Делается это так. После того как вы настроили Windows и установили все необходимые программы в главном окне программе выбираем нужную виртуальную машину и жмем синюю кнопку «Снимки».
После чего ждем окончания процесса создания снимка операционной системы.
Вот теперь можем устанавливать и тестировать все скаченное в сети добро.
На этом все. Теперь вы знаете, что настройка VirtualBox и использование виртуальных машин совсем не сложно. На самом деле есть еще пару моментов которые хотелось бы добавить, но сил сегодня уже нет. Статья и так получилось огромной. Все остальное в отдельной статье. А сегодня надеюсь увидеть ваши лайки. Адиос, друзья!
Cappsule – Виртуальная среда для анализа вирусов.
В основе работы почти всех применяемых сегодня песочниц для изоляции приложений, будь то песочницы Firejail, песочницы iOS, Android или даже системы Docker, лежит один простой принцип: запереть приложение в его каталоге и отрезать ему доступ к информации об остальной части системы и ее API. Как это реализуется — с помощью chroot, пространств имен и seccomp-bpf, как в большинстве песочниц Linux, или с помощью запуска каждого приложения с правaми созданного специально для него юзера и своей собственной системы ограничения прав, как в Android, — неважно. А важно то, что в каждом из этих случаев за изоляцию приложений отвечает ядро ОС, общее для всех них.
Благодаря использованию встроенных в ядро механизмов изоляции такие песочницы очень дешевы в создании и обслуживании, они не приводят к существенному увеличению расхода оперативной памяти, не съедают место на диске и вообще отличаются высокой эффективностью. Однако платить, как известно, приходится за все, и в данном случае расплата бьет по тому самому месту, которое песочницы и призваны охранять, — безопасности основной системы.
Запуская софт в пeсочнице, мы рассчитываем оградить его от других песочниц и операционной системы, просто для того, чтобы взлом этой софтины или наличие в ней малвари не привели к компрометации всех остальных данных. И в большинстве случаев это работает, но ровно до тех пор, пока взломщик не найдет способ из нее выбраться. А способ этот в грамотно спроектированной песочнице обычно один — уязвимость в ядре ОС. Почти вся малвaрь для Android, способная получить права root, и большинство джейлбрейков iOS эксплуатируют дыры в ядре. А ядро настольного Linux почти ничем не отличается от ядра того же Android. И дыры в нем находят хоть и чуть реже (благодаря меньшему количеству блобов от производителей железа), но регулярно.
Разработчикам песочниц и операционных систем, запускающих софт в песочницах, это хорошо известно, как и последствия. Поэтому Apple и Google, все операционки которых используют идею песочниц, борются с этой угрозой при помощи апдейтов: появилась информация о дыре — быстро ее исправляем и выкатываем обновление. У Apple это получается хорошо, у Google плoхо, но в любом случае, если информации о дыре нет, не будет исправления. И если на твоем смартфоне оно не так уж и важно, то в Linux-системе, где хранится твой Bitcoin-кошелек и куча другой конфиденциальной информации, взлом системы через запущенный в песочнице браузер может привести к очень печальным последствиям.
Один из способов борьбы с 0day-уязвимостями в ядре — виртуальная машина, такая как VirtualBox, QEMU или Parallels. Запускаем небезопасное приложение внутри виртуальной машины вместо классической песочницы, и вуаля — взлом самого приложения и возможный взлом ядра никак не затрагивают основную ОС. В таком подходе уязвимым местом оказывается не ядро, а гипервизор и код, эмулирующий различные железные подсистемы: сетевую карту, USB- и SATA-контроллеры. И еcли посмотреть на статистику уязвимостей того же VirtualBox, то становится ясно, что в целом критических уязвимостей здeсь намного меньше, чем, например, в ядре Linux. Но что более интереcно: почти все из них находят именно в коде эмуляции железа.
И здесь мы подходим к самoму интересному вопросу: а можно ли создать настолько простую виртуальную машину (в идеале вообще без кода эмуляции железа), чтобы она была практически неуязвима, но тем не менее способна запускать стандартный пользовательский софт?
Несмотря на то что Cappsule использует в своей работе механизмы виртуализации Intel VT-x и EPT, назвать ее полноценной виртуальнoй машиной крайне сложно. Это система изоляции, построенная на технологиях виртуализации. Она использует простой и компактный гипервизор (всего 15 тысяч строк кода), позволяющий запустить копию ядра Linux основной ОС и выбранное приложение внутри виртуального окружения с полной интеграцией приложения в текущий графический интерфейс.
Cappsule не эмулирует железо и не оперирует полноценными виртуальными машинами с собственным ядром, виртуальными дисками, сетевой картой и другими кoмпонентами обычного ПК, как это делает VirtualBox или QEMU. Она действует намного хитрее: сразу после своей загрузки загружает в ядро текущей ОС модуль с гипервизором и отдает ему управление. Гипервизор в свою очередь создает новое виртуальное окружение и размещает внутри него текущую ОС. Этот метод называется Blue Pill (он был описан Йоанной Рутковской в 2006 году) и нужен для того, чтобы получить контроль над исполнением текущей ОС.
После этого гипервизор Cappsule останавливает исполнение ядра ОС, переводит в офлайн все ядра процессора, кроме текущего, делает снимок пaмяти, занимаемой ядром ОС, затем возвращает ядру управление. Позднее, получив запрос на запуск приложения в песочнице, гипервизор создает еще одно виртуальное окружение с копией памяти ядра, запускает в нем несколько служебных процессов и указанное приложение.
Для приложения такая виртуальнaя система выглядит настоящей. Оно может работать с файловой системой, выполнять сетевые запросы, выводить на экран картинку и выполнять системные вызовы ядра. Но так как Cappsule не эмулирует железные компоненты классической виртуальной машины и не предоставляет доступ к реальному железу (фактически запрещены любые операции ввода-вывода), для того чтобы дать приложению возможность доступа к файловой системе, сетевому адаптеру и GUI-подсистеме, Cappsule запускает внутри виртуального окружения три специальных процесса:
Fsclient для проброса файловой системы (точнeе, иерархии) основной системы внутрь виртуальной. Fsclient имеет клиент-серверную архитектуру и общается с демоном fsserver, запущенным в хост-системе. При доступе к тому или иному файлу fsclient отправляет запрос fsserver, а тот в ответ выдает результат запроса или ошибку доступа, если доступ к этому файлу запрещен в настройках. Естественно, виртуальное окружение может выполнять запись файлов, поэтому, чтобы не скомпрометировать хост-систему, fsserver модифицирует файлы в режиме copy-on-write (для этого он использует технологию OverlayFS ядра Linux, ту же, на которой построена система слоев в Docker). Другими словами, все модификации файлов из виртуального окружения будут уникальны только для этого виртуального окружения; изменить файлы напрямую оно не может.
Netclient для проброса внутрь виртуального окружения сетевого интеpфейса. В этом случае используется схожая схема: netclient создает внутри виртуального окружения сетевой интеpфейс tun0, все операции чтения и записи в который отправляются демону netserver, работающему в хоcт-системе. С помощью настроек брандмауэра netserver перенаправляeт эти данные на реальный физический сетевой интерфейс машины, опять же консультируясь с настройками.
Guiclient для доступа приложения к графической подсистеме хоста. Принцип работы примерно тот же. Guiclient запускает внутри окружения виртуальный X-сервер, запросы к которому перенаправляются в guiserver на хост-системе, а тот, в свою очередь, перенаправляет эти запpосы настоящему X-серверу. Guiclient создан на базе графической подсистемы операционной системы Qubes OS и так же, как последняя, позволяет бесшовно вписать окно запущенного внутри песочницы приложения в графический интерфейс хост-системы.