id: Гость   вход   регистрация
текущее время 23:04 28/03/2024
Автор темы: grandalexey, тема открыта 03/11/2016 21:01 Печать
Категории: операционные системы
https://www.pgpru.com/Форум/UnixLike/Какбытьсграфическиминтерфейсом
создать
просмотр
ссылки

Подскажите как реализовать и можно ли вообще сделать.


На машине установлен debian и виртуальная машина.


Можно ли настроить дебиан в соответствие с этими вариантами (Или в соответствии с одним из них)?


1.Пользователь должен иметь возможность работать только с ОС запущенной в виртуальной машине и не иметь доступа к выполнению каких-либо действий напрямую в debian.
Идеально было бы – если бы пользователь при загрузке мог выбирать из списка ОС, которая будет запущена в VM.


2.Пользователь после загрузки debian должен иметь возможность работать только с VM – Запуская оттуда ОС (Одну или несколько). Никаких других действий в самом debian выполнять не должен, ни через графический режим, ни через консоль.



 
На страницу: 1, 2 След.
Комментарии
— Гость_ (04/11/2016 02:51, исправлен 04/11/2016 03:16)   профиль/связь   <#>
комментариев: 450   документов: 10   редакций: 13

Отличная шутка!



В полном смысле это делается только через проброс видеокарты в гостевую систему (PCI passthrough). Это работает не везде, требовательно к железу, не во всех конфигурациях запускается, может оказаться сложным в настройке. Частично – делается через направление графического вывода на конкретный физический дисплей (SDL или VNC), но тогда всё равно будет какая-то минимальная программка (окошко с SDL- или VNC-клиентом), выполняющаяся на хостовой системе от имени какого-то пользователя.


Ввиду сложности настройки и других тонкостей мало кто с этим заморачивается, а делают проще: есть ограниченный пользователь на хостовой системе, доверенный и считающийся нескомпрометированным, который соединяется с графическим режимом гостевой системы (или разных гостевых систем) в обычных иксах через VNC-клиент или по SDL. Внутри гостевой системы – свой пользователь, от его имени производятся все действия по работе с сетью. Поскольку на хост при правильной настройке передаётся только картинка, а все буферы изолированы, вылезти наружу гостевой пользователь может только через уязвимости в SSH- и VNC-клиентах, запускаемых на хостовой системе.



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



Переписали всё тот же пункт 1 другими словами. Не вижу коренных отличий.


Вообще, полную изоляцию можно сделать, и даже в каких-то коммерческих супер-пупер системах с закосом под милитари так делали (то ли в FAQ Wnonix было, то ли в FAQ Qubes), но первый же вопрос: как этой системой управлять? Как её обновлять? Как читать логи? Как конфигурировать сеть? Всё равно нужен интерфейс к хостовой системе хотя бы на уровне SSH-доступа. Даже в Tails он есть на уровне возможности получить в консоли рута и произвести необходимые манипуляции с ОС.


Даже при успешном пробросе видеокарты в гостевую все проблемы автоматически не решаются. Будет ли ваше железо поддерживать IOMMU? Если нет, то прямой доступ к видеокарте даст ещё один возможный способ гостевой системе вылезти из виртуализации в хост. Можно запустить, правда, две гостевых системы: в одной из них будет видеокарта, и она (гостевая система) будет использоваться для коннекта ко второй, целевой гостевой системе, где происходит работа. Это безопасней, чем с голой связкой с хостом, но достигается существенным усложнением настройки и большей требовательностью к ресурсам. Если взвесить все "за" и "против", я не уверен, что стоит связываться с вашей исходной постановкой задачи: сложно, громоздко, немасштабируемо, и что оно добавляет, в конечном счёте, к безопасности – это ещё надо оценивать.

— grandalexey (04/11/2016 21:45, исправлен 04/11/2016 21:46)   профиль/связь   <#>
комментариев: 33   документов: 9   редакций: 7
PCI passthrough

Благодарю вас за верную наводку.
Информацию нашел.
Попытаюсь разобраться.


и что оно добавляет, в конечном счёте, к безопасности – это ещё надо оценивать.

Тут интересно еще посмотреть с другой стороны.
Если цель не безопасность, а наблюдение за пользователями.


То есть – Я админ хоста на debian.
Рядовые пользователи хоста работают в гостевых ос, не догадываясь, что они гостевые (Собственно как было описано выше)
И я из под админа могу видеть все их действия в гостевых ос в реальном времени или писать их.


Если брать простой вариант – без виртуальных машин.
Тогда суперпользователь может смотреть действия пользователей.


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


Возможно я, что то не понимаю и все проще?

— Гость_ (04/11/2016 23:52)   профиль/связь   <#>
комментариев: 450   документов: 10   редакций: 13

Хорошо посмеялся. Не, если бабушка какая малограмотная и ей всё равно, она не заметит, а так-то работа в гостевой ОС определяется элементарно – достаточно взглянуть на логи и выхлоп основных утилит.


то всё остаётся почти так же.


Кто вам мешает на хостовой ОС подмонтировать образ (или файловую систему) гостевой ОС и читать логи оттуда? Кто вам мешает сделать дамп RAM, выделенной гостевой системе? А по этому дампу восстаналивается всё начиная с паролей и кончая процессами. У хоста полный контроль над всем. Единственное – я не знаю быстрого удобного способа проверки запущенных процессов (и управления ими) в гостевой машине. По дампу постфактум это восстановить можно, но это долго и непрактично, насколько мне представляется. Проще – логиниться и получать рутовый доступ в гостевую систему той или иной степени явности.
— grandalexey (12/11/2016 19:54)   профиль/связь   <#>
комментариев: 33   документов: 9   редакций: 7
Кто вам мешает сделать дамп RAM, выделенной гостевой системе?


А какой софт существует – чтобы это сделать?

А по этому дампу восстаналивается всё начиная с паролей и кончая процессами.


То есть этот дамп – превращается в iso образ и опять же запускается его из виртуальной машины.
Какой софт это делает iso образ из дампа?
— Гость_ (12/11/2016 23:10)   профиль/связь   <#>
комментариев: 450   документов: 10   редакций: 13

Не знаю, гуглите. Таким софтом в основном форензики занимаются.


При чём тут iso? Это просто образ RAM.
— grandalexey (15/11/2016 02:44)   профиль/связь   <#>
комментариев: 33   документов: 9   редакций: 7
Даже в Tails он есть на уровне возможности получить в консоли рута и произвести необходимые манипуляции с ОС.


Кстати по поводу Tails, Qubes и так далее..

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

Мне такая позиция показалась какой то недосказанной.
Что же эти самые профессионалы, каждый раз перепиливают ядро под конкретную задачу?
Сами реализуют механизм гарантированного уничтожения данных, как в Tails и другие механизмы?

Насколько я понимаю ( Если рассматривать "любительскую" схему – Хостовая ОС – Гостевые ОС поверх нее ), то никакими настроечными методами и затягиванием гаек (как в хостовой так и в гостевых ОС) – не получиться обеспечить такой функционал, как в ОС, самой целью создания которой изначально была -безопасность.
— Гость_ (15/11/2016 10:32, исправлен 15/11/2016 11:11)   профиль/связь   <#>
комментариев: 450   документов: 10   редакций: 13

В мире GNU/Linux с некоторых пор перекомпиляция ядра стала считаться моветоном, но есть такие задачи, где без неё, вероятно, не обойтись. Например, хочется ограничить функционал подключаемых USB-устройств, оставив только USB-накопители и запретив USB-мышь, USB-клавиатуру, USB-сетевые и всё остальное – как это сделать? Не знаю, можно ли это реализовать на уровне запрета подгрузки конкретных модулей ядра.



Да, хотя в Tails, должен признать, довольно продвинутые механизмы. Некоторые из них легко на обычном Linux не сделаешь.



Это вы про какую ОС? Точную копию Tails или Qubes создать будет проблематично, но кому это нужно? Точная копия мало кого идеально устраивает как по функционалу, так и по безопасности, поэтому цель создания собственной сборки – решить эти проблемы. В своих сборках что-то будет реализовано так же, как там, что-то – иначе.


К примеру, жмём на хоткей – и за 5-10 секунд для всей домашней директории гостевой ОС делается амнезия, жмём другой хоткей – и за 15-20 секунд для всей гостевой системы делается амнезия, при этом заодно происходит рестарт тор-цепочек. Это быстро и удобно, а остальные программы в других ОС (гостевых и хостовой) в это же время продолжают работать, как ни в чём ни бывало – ни в Tails, ни в Qubes такого нет. В Tails для этого понадобится полная перезагрузка, в Qubes – полный ручной рестарт конкретной гостевой ОС + ручная амнезия для дискового раздела. Легко ли это удобно заскриптовать в Qubes или, к примеру, в Whonix? Не уверен, вряд ли там предполагалось вмешательство в систему на таком низком уровне.


А если хочется сохранить некоторую временную информацию на других подключенных носителях? В описанной схеме это делается автоматически: сбросили куда-то, рефрешнулись, всё внешнее тут же снова на месте. А как это сделать в Tails или Qubes? Копировать на внешний носитель, рестартить систему, потом снова монтировать внешний носитель, вводить пароли на шифрование? И таких примеров можно придумать много.


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


Не все хотят работать с несменяемым Qubes'овским RedHat, потому что привыкли к другим дистрибутивам, или их задачи в других дистрибутивах решаются проще. Как и любые ОС для конечного пользователя, Qubes и Tails – не конструкторы. Переделать их под себя будет труднее, чем с нуля сделать своё. Возможно, какие-то полезные функции из этих ОС не удастся у себя сделать, но здесь, как всегда, всё упирается в компромисс между плюсами и минусами собственных сборок по сравнению со стандартными.

— grandalexey (16/11/2016 00:11, исправлен 16/11/2016 00:18)   профиль/связь   <#>
комментариев: 33   документов: 9   редакций: 7
Например, хочется ограничить функционал подключаемых USB-устройств, оставив только USB-накопители и запретив USB-мышь, USB-клавиатуру, USB-сетевые и всё остальное

А есле взглянуть еще шире:


Какая общая концепция применения виртуалок ?
«Разделяй и властвуй»


Разделить различные задачи по различным виртуалкам, настроив виртуалки исключительно с потребностями этих задач и урезав весь остальной (непотребный) функционал виртуалок (И главным образом – это каналы взаимодействия виртуалок с хостовой ОС).


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


Но с учетом того, что вся firmware может представлять опасность... (Как было сказано в теме про bootkit-ы ).


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


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


Получается зеркально
Отдельно слой разделения процессов по ОС.
И отдельно слой разделение устройств по ОС.


Возможно, что то подобное уже где то ;) реализовали.

— grandalexey (17/11/2016 02:00)   профиль/связь   <#>
комментариев: 33   документов: 9   редакций: 7
Жаль комментариев нет
Интересно было бы услышать мнения -
насколько идея вообще фантастическая?
— Гость_ (17/11/2016 12:04, исправлен 17/11/2016 12:07)   профиль/связь   <#>
комментариев: 450   документов: 10   редакций: 13

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


Например, сетевую карту можно вынести в отдельную ОС и сделать из неё ОС-файрвол. Видеокарту можно вынести в другую ОС, из-под которой будет осуществляться доступ к графическому выводу (VNC, SDL или напрямую, если программы запускаются локально). Может быть, для USB-слотов следует сделать отдельную ОС, которая будет работать как файловый сервер. Последние два примера – больше спекуляции, чем полезные идеи.


Проработка того, что надо делать, начинается с продумывания архитектуры и модели безопасности. Далее под эту архитектуру строится разделение по пользователям и по ОС. Первична здесь именно архитектура, а не разделение само по себе в виде "дай-ка я сделаю, а потом буду думать, зачем я это сделал, и что это мне дало".


Всех проблем с проприетарной firmware так точно не решить. Решаются ли надёжно хотя бы какие-то из этих проблем – тоже вопрос.

— Гость_ (19/11/2016 03:41, исправлен 19/11/2016 03:44)   профиль/связь   <#>
комментариев: 450   документов: 10   редакций: 13

man qemu-doc:


dump-guest-core=on|off
Include guest memory in a core dump. The default is on.

man xl:


dump-core domain-id [filename]
Dumps the virtual machine's memory for the specified domain to the filename specified, without pausing the domain.

Дамп делается теми же инструментами, которые используются для запуска виртуалок и управления ими. При дампе в случае Linux создаётся исполнимый ELF-файл размером с величину всей оперативки, выделенной под гостевую систему. Другими программами потом этот дамп можно проанализировать.

— grandalexey (19/11/2016 07:04)   профиль/связь   <#>
комментариев: 33   документов: 9   редакций: 7
В отдельную ОС, как правило, выносят конкретные устройства при чётком понимании, зачем это делается и для чего.

Например, сетевую карту можно вынести в отдельную ОС и сделать из неё ОС-файрвол. Видеокарту можно вынести в другую ОС, из-под которой будет осуществляться доступ к графическому выводу (VNC, SDL или напрямую, если программы запускаются локально). Может быть, для USB-слотов следует сделать отдельную ОС, которая будет работать как файловый сервер. Последние два примера – больше спекуляции, чем полезные идеи.


Почему больше спекуляции? Раскройте мысль!
Я тоже думал именно про сетевую и видюху, это то что в первую очередь вынести имеет смысл выносить.

Все меры должны приниматься на основе тех самых компромиссов, о чём обычно забывают.

Благодарю за ссылку. Я чуть позже напишу – как я вижу, то что я предложил в соответствии с этим списком.

Дамп делается теми же инструментами, которые используются для запуска виртуалок и управления ими.

Я интуитивно чувствовал – что так оно и должно быть.
Просто я пока небольшим наборок виртуалок пользовался. Оракловой в основном.

Другими программами потом этот дамп можно проанализировать.

Проанализировать его можно. И это очень хорошо.
Только полезно уметь именно восстановить процессы.
— grandalexey (19/11/2016 07:08, исправлен 19/11/2016 07:20)   профиль/связь   <#>
комментариев: 33   документов: 9   редакций: 7

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


Сказать сложно.


PS. К слову. Недавно наткнулся. Соотечественник наш (Бывший как я понял) Dmitry Vostokov. Большой вклад в это дело внес.
Целый 9-ти томник Memory Dump Analysis.


— Гость_ (19/11/2016 17:24, исправлен 19/11/2016 17:31)   профиль/связь   <#>
комментариев: 450   документов: 10   редакций: 13

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


Сетевая сюда сравнительно органично вписывается: файрвол – это конкретная задача на конкретном железе (сетевой карте). Преимущества понятны: можно выбрать отдельную ОС с надёжным и удобным в управлении файрволом и выставить её торчать наружу. Взаимодействие с другими ОС делается легко через виртуальные сетевые интерфейсы. Это в теории. А на практике всё не так гладко, и вылазит множество нюансов, которые заранее не участь, не начав разбираться с проблемой.


В Linux есть пресловутый файрвол – хоть и мощный по возможностям, но довольно сложный в настройке, отладке и управлении, а также полный разных неожиданных багов. Есть три инструмента, функционал которых частично перекрывается: iptables, arptables и ebtables. Чтобы написать простейшие правила, надо понимать, как всё это работает на нижнем уровне.


Я заметил, что в локалке кто-то занимается продвинутым ARP cache poisoning, которму подвержены все системы. Не то, чтоб он на что-то влияет (это, скорее, уязвимость против ISP), но неприятно. Чтобы защититься, попытался написать фильтрацию ARP, просидел какое-то время, но не получилось. Приходится либо разрешать всё, либо запрещать всё. arptables настолько туп, что там не отключить трансляцию IP-адресов в доменные имена. В принципе, ebtables функциональней arptables, и нет никаких причин использовать последний, но именно с последним мне удалось худо-бедно реализовать свою полумеру, которая как-то работает, хотя периодически приходится отключать правила, делать действия, а потом загружать заново.


В Linux на этот зоопарк смотрели-смотрели, и наконец-то он кому-то надоел. Теперь списки iptables, надеюсь, уйдут в прошлое, на их место пришёл nftables, который объединяет в себе функционал всех {ipt,eb,arp}tables, более PF-подобен и имеет структуру. Однако, есть два "но": первое – его надо изучать, а это время; второе – раз на большинство ОС в VM всё равно приходится ставить Linux, правильно поставить в качестве файрвола иную ОС с другим файрволом – в случае бага в линуксовом сетевом стеке она может подстраховать на последней миле.


Если не линукс, то кто? Кот? Здесь начинается самое интересное. Если нужна фильтрация по ARP, она помимо Linux есть на мостах в OpenBSD. Про DragonFly не знаю, FreeBSD вроде тоже умеет, NetBSD – нет. Но это только один нюанс.


Другой нюанс (довольно нетривиальный!) – в том, что только Linux и NetBSD поддерживают чисто паравиртуальный режим. DragonFlyBSD не поддерживает его вообще, OpenBSD (как и большинство ОС) – только паравиртуальные драйвера на HVM. А раз OpenBSD начали пилить свой VMM вместо поддержки стандартных гипервизоров, ждать от них полностью паравиртуального режима не приходится даже в будущем.


С FreeBSD всё ещё веселей: паравиртуальный режим там был, но его из ядра позже выкинули, потому что "не, ну а что, всё равно же будущее за PVH, поэтому не будем заморачиваться". Да и тогда, когда этот режим был, требовалось много плясок вплоть до перекомпиляции ядра, чтобы FreeBSD в этом режиме запустить. Это только NetBSD предоставляет готовые ядра и относительно простые инструкции для старта в паравиртуальном режиме.


Третий нюанс – в том, что сетевую (как PCI-устройство) можно передать в гостевую ОС, запущенную не на паравиртуальном режиме, только в том случае, если железо поддерживает IOMMU. Большинство железа, у меня сложилось такое впечатление, IOMMU не поддерживает. Мой случай таков. Итак, передача сетевой возможна только в полностью паравиртуальные ОС. Значит, там в качестве файрвола может стоять либо NetBSD без фильтрации ARP, либо всё тот же Linux со всеми его плюсами и минусами. А раз так, стоит ли овчинка выделки? Вот так идеальные теоретические рассуждения разбиваются о практическую реальность.




На самом деле, есть ещё один тонкий нюанс. В принципе, можно запустить реальную сетевую в прозрачном режиме, подцепив её к тому же мосту, куда крепится виртуальная сетевая гостевой ОС. Такой режиме считается непроизводительным и неэффективным, но кое-где описывается в сети. По крайней мере, вроде бы он должен работать. Однако, как я ни пытался, у меня не получилось. Мост пакеты и MAC-адреса видит, после включения proxy_arp и forwarding через sysctl начали ходить некоторые из пакетов из гостевой ОС вовне и обратно, но устойчивого канала не получилось. Гостевая ОС так и не смогла ни ARP-ответы получить, ни ping. Я немного поигрался и бросил затею.


А вообще, сложилось впечатление, что паравиртуальность опередила время, но теперь в соответствии с принципом worse is better победит не лучший, а более конформистский. Паравиртуальность была очень смелым шагом: выкинули всё полувековое тяжёлое наследие в виде виртуальных BIOSов, анахронических методов загрузки ОС, эмуляции реального железа, а оставили только то, что нужно. Всё разрушили до основания и сделали свой правильный мир с нуля. Конечно, это споткнулось о то, что основные игроки рынка подстраиваться не спешили, поэтому за пределами Linux и NetBSD это осталось маргинальщиной. Виртуалки же часто используют для старта непонятно каких ОС, а не для специальных ОС в специальных режимах, поэтому классикой виртуализации так и остался HVM. Правда, сторонники HVM по праву оценили заслуги паравиртуализации в производительности, но вместо того, чтобы допилить до ума паравиртуальный режим, ограничились утягиванием паравиртуальных драйверов. Теперь почти все ОС работают в этом режиме, он же PVHVM. Потом его доведут до ума и сделают гибрид PVH, а PV и HVM уйдут в историю.


Прокол паравиртуальности был и в том, что помимо сети и дисков они ничего не сделали для других устройств. Звук вроде бы недавно появился, а с видеокартой всё как было по старинке, так и осталось. Ладно, допустим, звук ещё можно гонять по сети через JACK, то видео по сети (VNC) никогда не будет таким же быстрым, как SDL. Как пишут в сети, PVHVM ест некоторые дополнительные ресурсы памяти по сравнению с PV, но на производительность сильно не влияет. В целом это соответствует истине.


Итог таков, что для многих задач на десктопе HVM удобней. Из коробки работает звук (достаточно указать одну опцию) и быстрое полноэкранное видео. Звук к PV – это убьёшься быстрее, чем настроишь JACK, да и его могут не все программы поддерживать + возникает опасность уязвимости в самом JACK (альтернатива – пробрасывать звуковую как PCI, но тогда звук в других ОС пропадёт). Видео в PV, пусть даже через VNC – тоже настраивать дольше, чем искоробочно работающий SDL. Правда, VNC гибок и универсален, VNC-окна можно закрывать и открывать заново – все приложения останутся на месте, а если закрыл SDL-окно, то снова его без рестарта системы не открыть и даже переключение на другие дисплеи почему-то не работает, т.е. в таком SDL-режиме с ОС может работать не больше одного пользователя. Остальные – либо по сети, либо через VNC.


Можно даже запустить виртуалку в виртуалке (гипервизор в гипервизоре) – это сказывается на тормозах в графическим I/O и порождает некоторые глюки типа невозможности на лету передавать блочные устройства, но это работает. Это удобно для отладки виртуалки, т.к. не нужно каждый раз перезагружаться.


Отдельный минус HVM – использование qemu для эмуляции железа. Как я подозреваю, ошибки к монстре под названием qemu могут привести к побегу гостей из виртуализации.



А что вам даст вынос видеокарты? Даже если у вас это получится (получается мало у кого, тут особые требования к железу), и IOMMU включено, значит, потенциально зловредный код гостевой ОС будет работать в т.ч. на этой видеокарте. Я не знаю, до какой степени страхует IOMMU в плане уязвимостей в фирмвари, но, как минимум, если есть требование максимально не доверять графике, самое безопасное – это, безусловно, VNC, которого хватает для всего помимо игр и полноэкранного видео. Режим с пробросом видеокарты надо сранивать с SDL и тоже понять, какие плюсы и минусы для безопасности от этого.


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



Не знаю. Если спецификации на железо открыты, драйвера открыты, исходный код есть, почему не получится? Когда железо есть, forenscope справляется. Когда нет – не знаю, обращайтесь с такими вопросами к реверсерам.

— grandalexey (23/11/2016 07:09)   профиль/связь   <#>
комментариев: 33   документов: 9   редакций: 7
Теперь списки iptables, надеюсь, уйдут в прошлое, на их место пришёл wwwnftables, который объединяет в себе функционал всех {ipt,eb,arp}tables, более PF-подобен и имеет структуру.


То есть в Debian 8 они уже есть?
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3