id: Гость   вход   регистрация
текущее время 08:56 24/08/2019
Автор темы: Гость, тема открыта 11/06/2012 23:16 Печать
Категории: анонимность, инфобезопасность, разграничение доступа
https://www.pgpru.com/Форум/ПрактическаяБезопасность/БезопасноеИспользованиеВиртуальнойОс
создать
просмотр
ссылки

Безопасное использование виртуальной ос

Интересуют практические аспекты безопастного использования виртуальной ос. Я считаю, если мы хотим анонимно работать из-под виртуальной ос, которая хранится на зашифрованном диске, то помимо обеспечения анонимного канала доступа в сеть на виртуальной ос должны быть проведены дополнительные мероприятия:
1) При каждом новом логине смена информации о ос и устройствах. (mac-адреса, серийные номера устройств, информация о версии ос, браузерах и.т.д.)
2) Ограниченные права пользователя (гость с дополнительными настройками).


Интересует прежде всего каким софтом можно обеспечить выполнение первого требования и в каких правах можно урезать гостя, какие службы отключить и.т.д.?



 
На страницу: 1, 2, 3, 4 След.
Комментарии
— Гость (05/07/2012 19:49)   <#>
TdR бы с вами не согласился.
— neverward (05/07/2012 20:07, исправлен 05/07/2012 20:12)   профиль/связь   <#>
комментариев: 43   документов: 0   редакций: 7

T

dR бы с вами не согласился.

о да bsdшники вообще консерваторы лютые, даже яндекс от них сбежал. Виртуализация даёт ring -1. А уж дальше всё зависит от программы гипервизора.
Угроза хост системе заключается в атаке на софт сетевого интерфейса со стороны Сети. Теоретически если там есть ошибки, то можно попасть в хост систему. Т.е. есть мост между хост системой и гостевыми. Ещё могут быть ошибки в реализации гипервизора или даже процессора. В остальных случаях если хост системе запрещено что либо делать кроме того как быть мостом и обслуживать виртуальные контейнеры можно рассчитывать на изоляцию. Гарантия конечно не 100%, как обычно, но она выше, чем при защите толкьо средствами ОС, так как гипервизор таки проще, чем ядро ОС, гораздо проще

— Гость (05/07/2012 20:13)   <#>
Т.е. есть мост между хост системой и гостевыми
в vmware предлагается использовать Nat.
Ещё могут быть ошибки в реализации гипервизора или даже процессора
так же зависит от производителя гипервизора, процессора, используемых систем (хоста и гостевой).
— neverward (05/07/2012 20:26)   профиль/связь   <#>
комментариев: 43   документов: 0   редакций: 7
в vmware предлагается использовать Nat.

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

в XEN HVM гостевая ОС не может напрямую влиять на реальное оборудование, в том числе память и процессор, что ИМХО является более высоким уровнем безопасности, что бы там не говорили.
— Гость (05/07/2012 20:32)   <#>
концепция виртуализации для защиты раньше оценивалась скептически. Докажет ли Рутковская обратное — неизвестно.
/comment38597. Типа, Qubes — это не просто гипервизор Xen, т.к. там ещё и аппаратная защита/изоляция систем есть.
— Гость (05/07/2012 20:37)   <#>
как гипервизор таки проще, чем ядро ОС, гораздо проще
К слову: если что, то вы, наверное, уже в курсе.
— Гость (05/07/2012 20:43)   <#>
что ИМХО является более высоким уровнем безопасности
Интересно, что значимее — ваше мнение или мнение основателя и идейного лидера проектов OpenBSD и OpenSSH, а также одного из основателей проекта NetBSD. Да и пруфлинк на эпик фейл Xen+Intel выше. За SELinux подобных фейлов не припоминается.
— neverward (05/07/2012 20:44)   профиль/связь   <#>
комментариев: 43   документов: 0   редакций: 7
Типа, Qubes — это не просто гипервизор Xen, т.к. там ещё и аппаратная защита/изоляция систем есть

недавно натыкался на сию ОС, концепция интересная, если оправдает себя, то возможно в будущем будет стандартом безопасности исполнение отдельный приложений в изолированной от реального оборудования среде.
— neverward (05/07/2012 21:00)   профиль/связь   <#>
комментариев: 43   документов: 0   редакций: 7
Интересно, что значимее — ваше мнение или мнение основателя и идейного лидера проектов OpenBSD и OpenSSH, а также одного из основателей проекта NetBSD. Да и пруфлинк на эпик фейл Xen+Intel выше

значимее мнение специалистов по безопасности конечно, но с другой стороны не раскрыта концепция уровня ring -1, т.е. непонятно почему полная изоляция гостевых ОС от реального железа и друг от друга не повышает безопасность скажем отдельного контейнера у которого нет сети и вообще связи с другими контейнерами. Мне интересно не личность, а физическая причина. Например сейчас понятно, что концепция ring таки повышает устойчивость к взлому. Т.е. изоляция программ от железа обязательна. Почему изоляция всей ОС от железа ни к чему не приведёт полезному?

SE как и любая система не может быть 100% надёжной, т.е. нужно чтобы в ОС была абсолютная гарантия от физического доступа атакующего приложения к hdd иначе будет руткит и 100% контроль над системой
— Гость (05/07/2012 21:08)   <#>
За SELinux подобных фейлов не припоминается.
Ой, да ладно вам! Вот эта новость (у нас тоже обсуждалось) или какая там? [где SeLinux в принципе помочь от local root не мог, т.к. в коде была логическая ошибка]. Про баги в самом SeLinux unknown пусть лучше расскажет:
Судя по количесту багов даже в правилах, поставляемых самими разработчикам SELinux, вполне возможно, что он хорош в теории, а на практике многое в плачевном состоянии.
— Гость (05/07/2012 21:14)   <#>
Наверно, TdR хотел сказать, что если ОС работает на реальном железе, есть уязвимости только в самой ОС. А если ОС работает в виртуалке, то потенциально есть узявимости в гипервизоре в нагрузке к уязвимостям в самой ОС. Изначально виртуалки не позицинировались как средство безопасности — это просто средство разделения ресурсов. Не стоит забывать, что TdR смотрит на ОС как на сервер-рутер, где прежде всего критичны remote exploit, а не как на систему для большей анонимности. Я бы не стал применительно к анонимности аппелировать к авторитету Тео, как к истине в последней инстанции, т.к. он имел в виду другие задачи и другие цели, другие модели угрозы.
— unknown (05/07/2012 21:23, исправлен 05/07/2012 21:24)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

И это позволяет разработчикам SELinux всегда отвечать, что никакой дыры в самом SELinux нет, а просто правила недоделаны.


Польза SELinux не в том, что он каким-то магическим способом нейтрализует баги, а просто резко снижает шансы использовать уязвимость при работе реальной программы, сервиса, пользователя, потому что им сильно режется доступ не только к файлам, но и к ресурсам, потенциальным действиям — к тому, что можно сделать.


Производители виртуалок (и создатели большинства программ) рекомендуют отключать SELinux при малейших глюках, потому что не имеют желания с ним разбираться. Создатели SELinux, наоборот, в последнее время продвигают идею SELinux-модулей для виртуалок. А также связки лёгких псевдовиртуальных контейнеров + SELinux для всяких песочниц (Sandbox).

— neverward (05/07/2012 21:29)   профиль/связь   <#>
комментариев: 43   документов: 0   редакций: 7
Наверно, TdR хотел сказать, что если ОС работает на реальном железе, есть уязвимости только в самой ОС. А если ОС работает в виртуалке, то потенциально есть узявимости в гипервизоре в нагрузке к уязвимостям в самой ОС. Изначально виртуалки не позицинировались как средство безопасности — это просто средство разделения ресурсов. Не стоит забывать, что TdR смотрит на ОС как на сервер-рутер, где прежде всего критичны remote exploit, а не как на систему для большей анонимности. Я бы не стал применительно к анонимности аппелировать к авторитету Тео, как к истине в последней инстанции, т.к. он имел в виду другие задачи и другие цели, другие модели угрозы.

полностью согласен. Плюс виртуальные контейнеры могут быть построены по разному, т.е. у каждого из контейнеров может быть включены минимально необходимые модули ядры и вообще выключена загрузка модулей на ходу. Целостность файлов контейнера может быть проверена из хост системы, т.е. в обмен на риск увеличения риска ошибок появляется возможность проверять гостевые ОС на любые взломы просто поставив её на паузу, это не считается как повышение, как и многое другое, что даёт гипервизор? Просто утверждение, защитный код с отдельным уровнем только ухудшает безопасность, просто из-за того, что кода стало больше и никак её не улучшает звучит как-то неполно, возможно мы не знаем весь контекст беседы, ссылку на которую привели выше
— Гость (05/07/2012 22:56)   <#>
защитный код с отдельным уровнем только ухудшает безопасность, просто из-за того, что кода стало больше и никак её не улучшает звучит как-то неполно

Есть два противоположных эффекта:

  1. Чем больше объём кода, чем сложнее его логика и чем больше функционал, тем, при прочих равных, он менее безопасен (система тем надёжней и безопасней, чем она проще).
  2. При прочих равных, чем лучше продумана архитектура кода, всякие разные страховки (SeLinux и др.), тем система более безопасна.

В своём время в рассылке был поучительный флейм на тему того, хорошо ли использовать механизмы типа strlcpy. Одни говорили, что это шаг к большей безопасности, т.к. защищает от непреднамеренных случайных ошибок с копированием строк в C. Другие же говорили, что это шаг к меньшей безопасности, т.к. оно добавляет очень нетривиальную семантику, и если вдруг возникнут ошибки, обнаружить их, найти и понять в чём они, будет намного тяжелее (но ошибки от этого не исчезнут). По-своему правы и те и другие. OpenBSD пошёл по первому пути, Linux — по-второму. Примерна та же дилемма, пожалуй, возникает и при обсуждении виртуалок.
— Гость (06/07/2012 00:47)   <#>
исполнение отдельный приложений в изолированной от реального оборудования среде
а что сейчас мешает в любой системе запускать каждое приложение в своей песочнице? или я неправильно понимаю, что вы имели ввиду?
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3