Все по песочницам! Запускаем приложения в отдельных виртуалках с помощью AppVM
Содержание статьи
Я действительно люблю Qubes. Если ты с ним не сталкивался, поясню: это дистрибутив, построенный на базе гипервизора Xen, который позволяет создавать домены — честные виртуальные окружения, внутри которых приложения работают в изоляции. Ты можешь создавать домены на базе разных дистрибутивов (образов), и они смогут общаться между собой: например, шейрить файлы. В Qubes доменов может быть сколько угодно: work, personal, vault — создавай и называй как хочешь. Звучит неплохо, но есть ли альтернативы и нужны ли они?
Если бы не Xen (вместо гипервизора :)) и отсутствие возможности использовать созданные его разработчиками утилиты вне окружения дистрибутива, то я бы им даже пользовался. Но, на мой взгляд, Xen не подходит хотя бы тем, что в отличие от KVM он не в ядре в апстриме. Предлагать кому-то устанавливать Xen, только чтобы воспользоваться какой-то тулзой, — сомнительное удовольствие. В Qubes самом по себе тоже ничего плохого нет, но его нужно устанавливать и настраивать. Гораздо проще начать встраивать все хорошее из Qubes к себе в уютную Gentoo, чем ломать годами отлаженную систему.
Однако идея безопасности через виртуализацию (security through virtualization) меня по-прежнему привлекала, поэтому что-то нужно было с этим делать.
Зачем вообще использовать Qubes или запускать приложения в отдельных виртуальных машинах?
Конечно же, для повышения безопасности! Чтобы минимизировать риски заражения через ненадежные программы. Например, ты знал, что любое приложение, которые ты запускаешь у себя, имеет доступ ко всем твоим авторизациям в Chrome на всех сайтах и может слить твои сессии и выполнить любые действия на любых сайтах от твоего имени? Или получить доступ к твоим файлам. Вот этого я и постарался избежать.
Я покажу, как запускать любые, даже GUI-приложения в виртуальной машине, а также шейрить между ними файлы и буфер обмена. Последнее — это, конечно, в теории потенциальная дыра, но жить без этого будет сложновато.
Чтобы реализовать такую схему работы, я написал AppVM и сейчас покажу, как с ним обращаться.
Запущенные в AppVM приложения с GUI. Удобный менеджер запущенных приложений с информацией о потребляемой памяти
Если ты не знаком с Nix, то будет полезно прочитать cheatsheet, который поможет понять, каким образом ведется работа в системе. А для тех, кто хочет попробовать NixOS (дистрибутив) или Nix (пакетный менеджер, которым можно пользоваться на любом дистрибутиве), будет полезно прочитать другую статью на той же вики.
Из чего строим
Изначально я видел решение в том, чтобы «собрать виртуальную машину для каждого приложения». Обернувшись блогами, как теплым клетчатым пледом, я начал искать готовые скрипты. Но все они мне показались весьма непривлекательными — за исключением примера, в котором использовался NixOS. Так и появилась первая версия AppVM, которая, по сути, была набором скриптов для установочного диска.
А как же другие системы изоляции?
В чем преимущество по сравнению с использованием SELinux или AppArmor, а быть может, еще и Firejail или bubblewrap? В лени. Виртуальные машины не только дают безопасность, их еще и проще использовать. Тебе не нужно ограничивать доступ к определенным ресурсам системы, если их просто нет.
Предельно простой конфигурационный файл Nix определил систему:
Решаем вопрос с GUI
Использовать виртуализацию для консольных приложений, конечно, здорово, но мне бы хотелось в первую очередь запускать GUI-приложения. Например, недоверенные PDF — ты же прекрасно знаешь, как дыряв формат PDF и сколько хитрых сплоитов можно через него провернуть, чтобы исполнить код на целевой системе. Без поддержки GUI смысл AppVM минимален.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Запуск приложения в отдельных виртуальных машинах с помощью AppVM
Если вы действительно заботититесь о безопасности, то некоторые приложения есть смысл запускать в виртуализации. Обычно это создает массу проблем: держать три десятка виртуалок неудобно и остается соблазн «по-быстрому» что-то запустить на хосте. Мне удалось обойти часть неудобств. Данное решение я назвал AppVM — оно работает в Linux и позволяет запускать приложения с GUI и шейрить файлы с основной системой; оверхеды при этом минимальны. Как я этого добился? Сейчас расскажу.
Я очень люблю Qubes. Если вы с ним не знакомы, поясню: это дистрибутив, построенный на базе гипервизора Xen, который дает возможность создавать домены — честные виртуальные окружения, внутри которых приложения работают в изоляции. Вы можете создавать домены на базе разных дистрибутивов (образов), и они смогут общаться между собой: например, шейрить файлы. В Qubes доменов может быть сколько угодно: work, persoanl, vault — создавайте и называйте как хотите. Звучит неплохо, но есть ли альтернативы и нужны ли они?
Если бы не Xen (вместо гипервизора :)) и отсутствие возможности использовать созданные его разработчиками утилиты вне окружения дистрибутива, то я бы им даже пользовался. Но, на мой взгляд, Xen не подходит хотя бы тем, что в отличие от KVM он не в ядре в апстриме. Предлагать кому-то устанавливать Xen, только чтобы воспользоваться каким-то инструментом, — не самое большое удовольствие. В Qubes самом по себе тоже ничего плохого нет, но его нужно устанавливать и настраивать. Гораздо проще начать встраивать все хорошее из Qubes к себе в уютную Gentoo, чем ломать годами отлаженную систему.
Однако идея безопасности через виртуализацию (security through virtualization) меня по-прежнему привлекала, поэтому что-то нужно было с этим делать.
Зачем запускать приложения в отдельных виртуальных машинах?
Конечно же, для повышения безопасности! Чтобы минимизировать риски заражения через ненадежные программы. Например, вы знали, что любое приложение, которые вы запускаетеу себя, имеет доступ ко всем вашим авторизациям в Chrome на всех сайтах и может слить ваши сессии и выполнить любые действия на любых сайтах от вашего имени? Или получить доступ к твоим файлам. Вот этого я и постарался избежать.
Я покажу, как запускать любые, даже GUI-приложения в виртуальной машине, а также расшаривать между ними файлы и буфер обмена. Последнее — это, конечно, в теории небезопасно, но жить без этого будет сложновато.
Чтобы реализовать такую схему работы, я написал инструмент AppVM и сейчас покажу, как с ним обращаться.
Если вы не знакомы с Nix, то будет полезно прочитать cheatsheet, который поможет понять, каким образом ведется работа в системе. А для тех, кто хочет попробовать NixOS (дистрибутив) или Nix (пакетный менеджер, которым можно пользоваться на любом дистрибутиве), будет полезно прочитать другую статью на той же вики.
Из чего строим
Изначально я видел решение в том, чтобы «собрать виртуальную машину для каждого приложения». Обернувшись блогами, как теплым клетчатым пледом, я начал искать готовые скрипты. Но все они мне показались весьма непривлекательными ― за исключением примера, в котором использовался NixOS. Так и появилась первая версия AppVM, которая, по сути, была набором скриптов для установочного диска.
А как же другие системы изоляции?
В чем преимущество по сравнению с использованием SELinux или AppArmor, а быть может, еще и Firejail или bubblewrap? В лени. Виртуальные машины не только дают безопасность, их еще и проще использовать. Вам не нужно ограничивать доступ к определенным ресурсам системы, если их просто нет.
Предельно простой конфигурационный файл Nix определил систему:
Решаем вопрос с GUI
Использовать виртуализацию для консольных приложений, конечно, здорово, но мне бы хотелось в первую очередь запускать GUI-приложения. Например, недоверенные PDF — вы же прекрасно знаете, как дыряв формат PDF и сколько хитрых сплоитов можно через него провернуть, чтобы исполнить код на целевой системе. Без поддержки GUI смысл AppVM минимален.
Первым делом мне понадобился графический сервер и какой-то минимальный оконный менеджер. Изначально я считал, что самое разумное решение — написать свою минималистичную реализацию оконного менеджера, которая будет делать только необходимое. Но, начав работу над этим, я осознал, что существует немало проблем, например с всплывающими окнами, и небольших особенностей, которых достаточно для того, чтобы более жирное, но отлаженное временем решение было предпочтительнее.
Почему нельзя работать вообще без оконного менеджера на голых «Иксах»? Потому, что многие приложения хотят показывать модальные и дочерние окна. Без хоть какого-нибудь оконного менеджера они будут работать некорректно.
В качестве временного решения я воспользовался xmonad, задействовав важнейшую фичу каждого тайлового оконного менеджера ― возможность разворачивать окно на весь экран. А после я осознал, что xmonad настолько незаметен в системе (потребляет всего 5 Мбайт с конфигом AppVM), что разумнее воспользоваться им, а функциональность при необходимости расширить.
Почему xmonad
В работе я пробовал много оконных менеджеров, но в итоге использую только xmonad, неизменно с середины 2012 года. За это время я не столкнулся ни с одним багом, ни разу не было падения или каких-либо проблем, мешающих работать. В основе этой программы — всего три тысячи строк на Haskell, а если убрать комменты, останется около двух. Для сравнения i3wm — около 40 тысяч строк на С, а mutter из проекта GNOME — 150 тысяч строк. Легковесность победила!
В итоге определенный конфигурационный файл Nix собирался в ISO:
После чего запускался с помощью QEMU:
Это работало, и это было хорошо. Но недостаточно. Проблема в том, что каждое приложение требовало включать в ISO все системные библиотеки и файлы, — когда используется одно или два приложения, это еще приемлемо, но если их пять-семь, то уже не доставляет.
Решение не заставило себя ждать, и оно при этом уже было частью проекта Nix:
Выглядит как то, что мне и было нужно!
Скучный 0day с VM escape, который я так и не зарепортил
Немного опробовав готовое решение в деле, я начал адаптировать его к своим хотелкам и попутно нашел скучный «0day» — возможность выйти за пределы VM. Как видно в описании модуля, Nix store (суть которого — директория /nix) расшаривается с гостевой ОС. Тут-то собака и оказалась зарыта.
Можно было бы подумать: «Ага! security_model=none!», но нет. Они забыли добавить опцию readonly, тем самым сведя выход из виртуальной машины всего к двум действиям:
Подробнее об опциях VirtFS можно прочитать в вики QEMU.
Как хранить данные?
У меня в качестве хранилища файлов конфигурации использовался диск qcow2, подключенный в режиме writeback. Туда и записывалась разница между исходной запущенной системой и внесенными изменениями. Проблема такого подхода проявилась очень быстро, а если точнее ― после первого же обновления: при использовании дисков в режиме «писать только разницу» обновить базовую систему не получится, так как она в этом случае будет другой.
Подключаем libvirt и разбираемся с правами
Тут стало понятно, что запуск QEMU из терминала недостаточно удобен, так как приложения «теряются». Их либо приходилось убивать руками (звучит пугающе, я знаю), либо нужно писать обертку, которая будет следить за ними. Это привело меня к libvirt.
Для тех, кто не сталкивался с libvirt, поясню, что это такое. Эта библиотека обеспечивает простую возможность управления виртуальными машинами как из терминала, так и из GUI (virt-manager) и при этом поддерживает разные системы виртуализации (как слой абстракции). Одна из полезных особенностей — то, что при использовании с QEMU/KVM libvirt в отличие от VirtualBox не требует установки дополнительных драйверов.
Существует возможность конвертировать командную строку QEMU в описание libvirt — это значительно облегчило мне переход. Проблемы проявились позже из-за того, что QEMU начал запускаться от другого пользователя.
Сначала я пытался решить проблему стандартными методами, с помощью ACL и бита sgid (если установить его на директорию, то можно автоматически присваивать права доступа на созданные файлы владельцу директории). Но к сожалению, QEMU создавал новые файлы на хостовой системе с правами 00 для group и other, что мешает использовать все перечисленное выше (или я в чем-то ошибся, не дойдя до решения).
Вопреки моим ожиданиям, suid на директорию работает иным образом. Подробнее об этом можете почитать в документации проекта GNU для coreutils.
Как аллоцировать память
Мне оставалось еще решить проблему с потреблением памяти. Статическое выделение слабо подходит для большого количества приложений, а проект по автоматическому изменению памяти Automatic Ballooning, к сожалению, с 2013 года не продвигался. В апстриме этого нет.
Вооружившись изолентой и костылями, я написал свою реализацию — безусловно, временную (хотя все временное имеет свойство становиться постоянным). Сложно ее назвать элегантной, но она, как ни странно, работает. Идея до безумия проста и состоит в создании задачи cron в гостевой системе.
Начинаем работать с VirtualBox
(для чайников)
2014.12.12. | Автор: Поисов Д.А.
В качестве примера я буду использовать VirtualBox 4.3.20 for Windows и гостевую операционную систему ubuntu-12.04. А устанавливать и настраивать все это буду в хостовой операционной системе Window 7.
Содержание.
1. Устанавливаем виртуальную машину VirtualBox 4.3.20 for Windows.
Удобнее всего скачивать дистрибутив виртуальной машины с официального сайта «www.virtualbox.org», со странички https://www.virtualbox.org/wiki/Downloads. Там вы найдете все последние версии виртуальной машины для большинства популярных операционных систем. Я скачиваю для операционной системы Windows (рисунок 1).
Дистрибутив VirtualBox 4.3.20 for Windows представлен в виде одного исполняемого файла VirtualBox-4.3.20-96997-Win.exe объемом 105 Мб.
После запуска исполняемого файла открывается окно, информирующее о подготовке к началу установки программы (рисунок 2).
Через несколько секунд откроется окно помощника установки. Для начала установки нажимаем кнопку «Next». После чего откроется окно выбора объема и места установки (рисунок 3).
По умолчанию будет предложено провести установку всех компонентов виртуальной машины, не советую без надобности отключать установку каких либо компонентов, так как все они понадобятся даже при минимальном использовании виртуальной машины. Так же по умолчанию будет предложено установить программу в папку «Programs Files\Oracle\VirtualBox\» и здесь я ничего не буду менять. Для перехода к следующему этапу установки жмем кнопку «Next».
В открывшемся окне (рисунок 4) будет предложены базовые настройки запуска виртуальной машины:
— создать ярлык на рабочем столе;
— создать ярлык в панели быстрого запуска;
— зарегистрировать расширения файлов Virtual Box в операционной системе.
Из этих настройки я оставлю первую и третью, но тут дело вкуса и привычки.
Для продолжения установки жмем «Next», после чего откроется окно (рисунок 5) предупреждающее, что в процессе установки будет разорвано сетевое соединение. Чтобы избежать потери данных желательно заверить работу приложений использующих сетевой соединение и дождаться завершения закачки всех данных из сети.
Сетевое соединение будет прервано всего на несколько секунд и затем автоматически восстановится, поэтому смело жмем копку «Yes» для перехода к следующему этапу подготовки к установке. В открывшемся окне (рисунок 6) сообщается, что все необходимые подготовки к установке программы произведены и можно приступать к установке. Для начала установки нажмите кнопку «Install» и перед вами откроется окно, показывающее процесс установки (рисунок 7).
В процессе установки операционная система будет спрашивать подтверждение разрешения установки контроллеров USB-канала для виртуальной машины (рисунок 8), сетевых адаптеров (рисунок 9) и сетевых служб (рисунок 10).
Для удобной работы с виртуальной машиной желательно иметь возможность доступа к контроллерам USB и работы с сетью, поэтому соглашаемся с установкой данных компонентов.
После того, как установка закончится, на экране откроется окно, сообщающее об этом долгожданном событии (рисунок 11). Нажмите кнопку «Finish» для завершения установки и перехода к созданию и настройки виртуальной машины.
2. Создаем виртуальную машину.
Ну что же, приступим к созданию виртуальной машины. Будет это не сложнее, чем установить VirtualBox. И так, запускаем VirtualBox и перед нами открывается главное окно программы (рисунок 12).
Для создания виртуальной машины жмем кнопку 
или выбираем пункт меню: «Машина->создать» или жмем сочетание клавиш Ctrl+N. В открывшемся окне (рисунок 13) задаем имя виртуальной системы, тип и версию гостевой операционной системы.
Моя виртуальная машина будет называться «VM». Так как я решил использовать в качестве гостевой системы ubuntu-12.04, то тип гостевой системы будет Linux, а версия – Ubuntu (32 bit). После установки требуемых параметров жмем «Next».
В открывшемся окне (рисунок 14) выбираем размер оперативной памяти отводимой для виртуальной машины.
В большинстве случаев хватает предлагаемых по умолчанию 512 мб памяти. Если у вас мало оперативной памяти, то этот размер можно уменьшить, но не ставьте слишком мало, так как это может сказаться на быстродействии виртуальной машины. При необходимости, если в виртуальной машине требуется запускать ресурсоёмкие приложения, объем выделяемой оперативной памяти можно увеличить. После выбора объема оперативной памяти жмем «Next».
В следующем окне (рисунок 15) необходимо выбрать виртуальный жесткий диск с которым будет работать виртуальная машина.
Существует два варианта: выбрать уже готовый или создать новый. Так как мы только начинаем работать с VirtualBox, то уже созданный виртуальных жестких дисков у нас нет, поэтому выбираем «Создать новый виртуальный жесткий диск» и жмем «Создать».
В открывшемся окне (рисунок 16) жмем в первую очередь на кнопку «Срыть подробности». В данной версии VirtualBox ошибка перевода или наименования данной кнопки и при нажатии кнопки «Скрыть подробности» отображается окно с подробными настройками создаваемого виртуального жесткого диска.
После нажатия кнопки «Скрыть подробности» открывается окно с расширенными настройками жесткого диска (рисунок 17).
В первую очередь выбираем тип виртуального жесткого диска. Для обеспечения совместимости с другими программами виртуализации присутствует возможность создавать виртуальные жесткие диски нескольких типов, например жёсткие диски VMDK могут использоваться с виртуальными машинами VMware.
Так как цель данной статьи дать базовые навыки работы с виртуальной машиной VirtualBox, то я выберу тип виртуального диска VDI – формат жёстких дисков предназначенных для работы с виртуальными машинами VirtualBox.
Далее немного увеличу размер создаваемого жесткого диска, до 10 Гб и сделаю его фиксированным, для облегчения контроля ресурсов занимаемых виртуальной машиной.
ВНИМАНИЕ: убедитесь, что на вашем жёстком диске достаточно места для создания виртуального жёсткого диска, прежде чем начать его создавать.
Для создания виртуального женского диска жмем «Создать». После чего откроется окно иллюстрирующее процесс создания жесткого диска (рисунок 18). Это может занять несколько минут.
Созданный виртуальный диск – это обыкновенный файл в хостовой операционной системе с указанным вами названием и расширением VDI. Этот файл можно перемещать, копировать, переносить на другой компьютер. Например, если Вам необходимо работать с одной и той же виртуальной машиной дома и в офисе, то можете на флэшке переносить файл жесткого диска и работать дома и в офисе с одной и той же виртуальной машиной.
После создания виртуального жесткого диска, в основном окне программы VirtualBox появится новая виртуальная машина, готовая к использованию (рисунок 19). Остаётся только установить на нее гостевую операционную систему.
3. Устанавливаем гостевую операционную систему.
Установка гостевой операционной системы начнется автоматически после первого запуска виртуальной машины. И так, запускаем виртуальную машину, нажав кнопку 
. Через несколько секунд откроется окно (рисунок 20), в котором будет предложено указать путь к загрузочному диску или образу загрузочного диска.
Я буду устанавливать операционную систему из образа загрузочного диска (ubuntu-12.04-oem-i386.iso), заранее скаченного RuTracker.org. Для выбора образа загрузочного диска жмем кнопку 
и в открывшемся окне (рисунок 21) выбираем файл ubuntu-12.04-oem-i386.iso, жмем кнопку «открыть» и для начала установки операционной системы в окне (рисунок 20) жмем кнопку «продолжить».
Сразу же после нажатья кнопки запустится виртуальная машина (рисунок 22) и через несколько секунд автоматически начнется установка гостевой операционной системы. В процессе установки операционной системы перед вами будут появляться подсказки, призванные облегчить работу с виртуальной машиной.
Установка гостевой операционной системы будет происходить ровно так же, как и при установки данной операционной системы на реальную ЭВМ или на виртуальную машину VMWare. Так как я уже описывал процесс установки схожей операционной системы в статье «Начинаем работать с VMware Workstation», в разделе установка гостевой операционной системы, то не буду повторяться и сразу перейду к описанию основ работы с виртуальной машиной.
4. Базовые операции с виртуальной машиной.
4.1. Запуск виртуальной машины
Запустите программу виртуализации VirtualBox. На экране откроется основное окно программы (рисунок 23).
Если в левой части открывшегося окна, в списке доступных виртуальных машин, нет нужной Вам, то выберите пункт меню:
В списке виртуальных машин в окне (рисунок 23) выберите нужную Вам. Я выберу виртуальную машину с именем «VM» и запустите выбранную виртуальную машину одним из следующих способов:
— нажав кнопку вверху окна, под меню «Правка»;
— выбрав пункт меню: Машина->Запустить.
После запуска виртуальной машины, если было сохранено ее состояние, произойдёт автоматическое восстановление состояния виртуальной машины и вы сможете продолжить работу, как будто не выключали виртуальную машину. Если состояние виртуальной машины не сохранялось, то произойдет запуск установленной гостевой системы, аналогично запуску операционной системы при включении реального компьютера.
4.2. Установка виртуальной машины на паузу.
Часто бывает необходимо временно отлучиться с рабочего места. Если в этот момент работает некая программа и Вам нельзя пропустить какой-либо важный момент в процессе работы данной программы, то в VirtualBox предусмотрена возможность временно приостановить работу виртуальной машины. Для этого необходимо выбрать пункт меню: Машина->Приостановить, при этом виртуальная машина автоматически встанет на паузу. Для возобновления работы повторно выберите пункт меню: Машина->Приостановить.
Естественно можно завершить работу виртуальной машины с сохранением состояния, а затем вновь запустить работу виртуальной машины, но это гораздо дольше. Если установка на паузу занимает доли секунды, то сохранение состояния может занимать несколько десятков секунд. Если приходится часто отвлекаться, то на паузу ставить гораздо удобнее.
4.3. Выключение виртуальной машины.
Завершить работу с виртуальной машиной можно несколькими способами:
1. Нажать кнопку завершения работы в правом верхнем углу окна (рисунок 24). В открывшемся меню (рисунок 25) выбрать один из следующих пунктов:
— «Сохранить состояние машины», при этом состояние машины будет сохранено, а затем виртуальная машина завершит работу. При следующем запуске состояние виртуальной машины будет автоматически восстановлено и работа продолжится, как будто вы не выключали виртуальную машину.
— «Послать сигнал завершения работы», при этом откроется окно завершения работы, вид которого зависит от используемой операционной системы. Используя данное окно, вы сможете штатно завершить работу гостевой операционной системы, при этом, после завершения работы гостевой операционной системы, работа виртуальной машины завершится автоматически.
— «Выключить машину». Данное действие эквивалента обесточиванию реальной машины.
Обращу Ваше внимание, в версии VirtualBox, используемой в данной программе, не зависимо от Вашего выбора в окне завершения работы операционной системы, через несколько секунд после выбора «Послать сигнал завершения работы» виртуальная машина выключается.
2. Штатным способом, предусмотренным гостевой операционной системой, завершить работу гостевой операционной системы, при том работа виртуальной машины автоматически завершится после завершения работы гостевой операционной системы.
5. Выбрать пункт меню: Машина->завершить работу, при этом откроется окно завершения работы, вид которого зависит от используемой операционной системы. Используя данное окно, вы сможете штатно завершить работу гостевой операционной системы, при этом после завершения работы гостевой операционной и системы работа виртуальной машины завершится автоматически.
Обращу Ваше внимание, в версии VirtualBox, используемой в данной программе, не зависимо от Вашего выбора в окне завершения работы операционной системы, через несколько секунд, после выбора пункта меню «Машина->завершить работу», виртуальная машина выключается.
4.4. Подключение съемных устройств к виртуальной машине.
Рассмотрим подключение съёмных устройств на примере подключения и отключения USB- накопителя.
Для подключения USB-накопителя выберите пункт меню: Устройства->USB-устройства и в открывшемся списке (рисунок 27) выберите нужное Вам USB-устройство. В моем случае, USB-накопитель определился как «Generic Mass Storage».
После выбора пункта меню «Generic Mass Storage» произойдет подключение USB-накопителя, как будто вы подключили флэшку к настоящему компьютеру, а в списке (рисунок 27) выбранное устройство будет отмечено галочкой. Дальнейшие действия определяются используемой Вами операционной системой. Для отключения USB накопителя снимите установленную галочку в том же меню. Как видите все очень просто.
ВНИМАНИЕ! При подключении съемного устройства к виртуальной машине, оно отключается в хостовой операционной системе, что может привести к потере несохраненных данных. По этому, прежде чем подключить съемное устройство к виртуальной машине, убедитесь, что Вы с ним не производите никаких действий в хостовой операционной системе.
4.5. Переключение между хостовой и гостевой операционными системами.
При работе в виртуальной машине, производится «захват» клавиатуры и мышки, то есть все нажатия на клавиатуры или действия мышкой обрабатываются виртуальной машиной и игнорируются в хостовой операционной системе. Для того, чтоб перейти на работу с хостовой операционной системой, необходимо нажать «Хостовую» клавишу или сочетание клавиш. Для различных версий виртуальных машин и в зависимости от их настроек «Хостовая» клавиша может быть разной, однако наименование клавиши отображается в правом нижнем углу окна виртуальной машины (рисунок 28).
При нажатии на данную клавишу обработка всех событий от клавиатуры и мышки вновь стане обрабатываться хостовой операционной системой. Для того, чтобы вернуться в работу с виртуальной машиной достаточно просто нажать мышкой в произвольное место окна ритуальной машины.
Этого вполне достаточно для начала работы с виртуальной машиной, а в дальнейшем, если Вам понравится новый инструмент, а он непременно Вам понравится, Вы с легкостью изучите все его возможности, а я Вам постараюсь помочь в одной из следующих статьей.