Безопасное использование виртуальной ос
Интересуют практические аспекты безопастного использования виртуальной ос. Я считаю, если мы хотим анонимно работать из-под виртуальной ос, которая хранится на зашифрованном диске, то помимо обеспечения анонимного канала доступа в сеть на виртуальной ос должны быть проведены дополнительные мероприятия:
1) При каждом новом логине смена информации о ос и устройствах. (mac-адреса, серийные номера устройств, информация о версии ос, браузерах и.т.д.)
2) Ограниченные права пользователя (гость с дополнительными настройками).
Интересует прежде всего каким софтом можно обеспечить выполнение первого требования и в каких правах можно урезать гостя, какие службы отключить и.т.д.?
комментариев: 43 документов: 0 редакций: 7
T
о да bsdшники вообще консерваторы лютые, даже яндекс от них сбежал. Виртуализация даёт ring -1. А уж дальше всё зависит от программы гипервизора.
Угроза хост системе заключается в атаке на софт сетевого интерфейса со стороны Сети. Теоретически если там есть ошибки, то можно попасть в хост систему. Т.е. есть мост между хост системой и гостевыми. Ещё могут быть ошибки в реализации гипервизора или даже процессора. В остальных случаях если хост системе запрещено что либо делать кроме того как быть мостом и обслуживать виртуальные контейнеры можно рассчитывать на изоляцию. Гарантия конечно не 100%, как обычно, но она выше, чем при защите толкьо средствами ОС, так как гипервизор таки проще, чем ядро ОС, гораздо проще
так же зависит от производителя гипервизора, процессора, используемых систем (хоста и гостевой).
комментариев: 43 документов: 0 редакций: 7
я имею в виду, что в реализации NAT могут быть ошибки, но шанс этого куда ниже, чем шанс ошибки в браузере
в XEN HVM гостевая ОС не может напрямую влиять на реальное оборудование, в том числе память и процессор, что ИМХО является более высоким уровнем безопасности, что бы там не говорили.
комментариев: 43 документов: 0 редакций: 7
недавно натыкался на сию ОС, концепция интересная, если оправдает себя, то возможно в будущем будет стандартом безопасности исполнение отдельный приложений в изолированной от реального оборудования среде.
комментариев: 43 документов: 0 редакций: 7
значимее мнение специалистов по безопасности конечно, но с другой стороны не раскрыта концепция уровня ring -1, т.е. непонятно почему полная изоляция гостевых ОС от реального железа и друг от друга не повышает безопасность скажем отдельного контейнера у которого нет сети и вообще связи с другими контейнерами. Мне интересно не личность, а физическая причина. Например сейчас понятно, что концепция ring таки повышает устойчивость к взлому. Т.е. изоляция программ от железа обязательна. Почему изоляция всей ОС от железа ни к чему не приведёт полезному?
SE как и любая система не может быть 100% надёжной, т.е. нужно чтобы в ОС была абсолютная гарантия от физического доступа атакующего приложения к hdd иначе будет руткит и 100% контроль над системой
комментариев: 9796 документов: 488 редакций: 5664
И это позволяет разработчикам SELinux всегда отвечать, что никакой дыры в самом SELinux нет, а просто правила недоделаны.
Польза SELinux не в том, что он каким-то магическим способом нейтрализует баги, а просто резко снижает шансы использовать уязвимость при работе реальной программы, сервиса, пользователя, потому что им сильно режется доступ не только к файлам, но и к ресурсам, потенциальным действиям — к тому, что можно сделать.
Производители виртуалок (и создатели большинства программ) рекомендуют отключать SELinux при малейших глюках, потому что не имеют желания с ним разбираться. Создатели SELinux, наоборот, в последнее время продвигают идею SELinux-модулей для виртуалок. А также связки лёгких псевдовиртуальных контейнеров + SELinux для всяких песочниц (Sandbox).
комментариев: 43 документов: 0 редакций: 7
полностью согласен. Плюс виртуальные контейнеры могут быть построены по разному, т.е. у каждого из контейнеров может быть включены минимально необходимые модули ядры и вообще выключена загрузка модулей на ходу. Целостность файлов контейнера может быть проверена из хост системы, т.е. в обмен на риск увеличения риска ошибок появляется возможность проверять гостевые ОС на любые взломы просто поставив её на паузу, это не считается как повышение, как и многое другое, что даёт гипервизор? Просто утверждение, защитный код с отдельным уровнем только ухудшает безопасность, просто из-за того, что кода стало больше и никак её не улучшает звучит как-то неполно, возможно мы не знаем весь контекст беседы, ссылку на которую привели выше
Есть два противоположных эффекта:
В своём время в рассылке был поучительный флейм на тему того, хорошо ли использовать механизмы типа strlcpy. Одни говорили, что это шаг к большей безопасности, т.к. защищает от непреднамеренных случайных ошибок с копированием строк в C. Другие же говорили, что это шаг к меньшей безопасности, т.к. оно добавляет очень нетривиальную семантику, и если вдруг возникнут ошибки, обнаружить их, найти и понять в чём они, будет намного тяжелее (но ошибки от этого не исчезнут). По-своему правы и те и другие. OpenBSD пошёл по первому пути, Linux — по-второму. Примерна та же дилемма, пожалуй, возникает и при обсуждении виртуалок.