Tor под виртуальной машиной
Установил virtualbox под Линуксом (т.к. мне нужна для винда для работы определенных программ).
Программы сетевые, хочу их заторить.
Соответственно, у меня после установки винды соединения из виртуальной машины шли незаторенные. (На линуксе стоит тор, но выхожу в инет и через тор, и не через тор, заториваю отдельные приложения).
Соответственно, установил в вирт. машине пакет tor-vidalla-privoxy для винды, удалось установить заторенное соединение.
Как при такой схеме все-таки лучше торить, черз тор-клиент, поднятый в вирт. машине, или через тор-клиент физической машины? И как в последнем случае торить?
P.S. И еще. Кто-то может описать, чем лучше для повышения анонимности выходить в Сеть через тор с виртмашины?! (Это не для того случая, где винда, для общих целей я лучше установлю еще одну линуху под вирт. машиной).
Может ли, например, включенный J при таком подключении украсть внешний ip, как он это делает в случае с физической машиной? Или он украдет "внешний" ip, который будет тождественен с внутренним ip физической машины?!
Лучше тем, что перед каждым выходом в интернет можно восстанавливать контрольную точку для удаления новых троянов и логов старых. правда я считаю что опасность заражения физической машины из виртуалки больше, даже чем при использовании ограниченной учетки (в Linux)
Как такое может быть? Что может сделать программа под виртуалкой и не может без неё?
Могут быть уязвимости в виртуалке (как правило в драйверах оборудования), а она имеет высокий уровень привилегий в физической машине. Ну разве что на лоре проскакивала ссылка на java x86 эмулятор
1. А можно поподробнее о механизмах заражения физической машины через виртуальную?
P. S. Вроде всегда считалось, что наоборот, нет угроз для физической машины, если юзать вирт.
2. И что мне теперь, на виртуалку устанавливать антивирус и пропиетарный фаервол?! (Я ей собираюсь, в т.ч., для финансовых целей пользоваться, т.к. у меня не все терминалы банкингов под линухой пашут).
А можно поподробнее, зачем вам столько терминалов? ;)
Не удержусь процитировать известный перл[link1]:
Цитату не найду, но создатели Selinux (и многие другие) говорят нечто похожее про виртуализацию — это средство управления системами, но не обеспечения безопасности. Правда ДеРаадт говорит нечто критическое про Selinux, а сторонники Selinux про недостижимость модели идеального кода самого ДеРаадта. Каждый (не) прав по-своему.
Мне в голову некогда приходила вот такая анология, не знаю насколько уместная. Допустим, что мы хотим построить кирпичный дом с непроницаемыми стенами, но в силу неидеальностей большинство используемых кирпичей имеют сквозные, случайно расположенные, отверстия. Можно использовать две стратегии: либо тщательно отбирать кирпичи и перепроверять их на наличие отверстий (OpenBSD), что позволяет делать более тонкие (простые) непроницаемые стены, либо не заботиться о качестве кирпичей, но делать кладку потолще, снижая вероятность появления сквозного отверстия сквозь всю стену (SeLinux). Т.о., во втором подходе "дыры закрываются другими дырами" в почти буквальном смысле, но есть надежда на то, что "вероятность критического дыросовпадения мала". Естественно, оба подхода неидеальны, оба имеют свои преимущества и недостатки, а реальное развитие вещей идёт в рамках обеих подходов. В частности, kauth в NetBSD[link2] и systrace в OpenBSD[link3] есть упрощёные аналоги SeLinux'а (впрочем, на systrace, судя по всему, подзабили). Равно и упрощение/оптимизация кода/интерфейсов в Linux есть суть первый подход.
Аналогия с Selinux'ом неверна. Не путайте его с другими средствами укрепления безопасности. Его задачи — выявить как можно больше вариантов взаимодействия программы с ОС и как можно компактнее описать их в виде правил, разрешив нужные и запретив ненужные (запрет бывает целевой или по умолчанию — самый сложный в настройке). Цель — максимальное ограничение ресурсов, доступных программе. Только необходимые для работы виды действий.
Проблемы тут такие:
1) правил может быть очень много и не получиться компактного описания в виде ясной политики
2) нужно досконально знать потроха системы и работающей программы
3) когда нужно выдать разрешение только на те действия, которые необходимы, можно ошибиться и разрешить лишние – пропустим дыру, если не допустить нужные — получим глюки программы.
4) если дыры окажутся в разрешённых действиях, то Selinux не поможет
5) дыры могут быть в самом Selinux
6) Модель Selinux может быть неполна (не все типы действий можно ограничить, хотя Selinux — максимально полная модель, стремящаяся регулировать всё, на что способно ядро).
Почему же неверна? Насколько я знаю, SeLinux – некий кусок ядра, т.е. дыры остальных программ/систем пытаются закрыть довлеющим над оными дополнительным куском кода, потенциально могущем иметь те же проблемы что и код, им защищаемый. Т.е. дело не только в том, что от каких-то дыр он может не спасти, но и в том, что (не в последнюю очередь из-за своей сложности) может внести совершенно новые, каких раньше не было.
Для внесения ясности ответ на изначальный вопрос я бы оформил так. Не стоит полагаться на виртуализацию при конструировании серьёзных высокозащищённых систем, как на некую панацею от. В то же время, от неё потенциально могут быть и плюсы и минусы: плюс – потому что для того, чтобы добраться до данных, хранимых из основной ОС, надо ещё взломать виртуальную машину (это как дополнительный замок на двери), минус – в том, что сама виртуальная машина может внести дополнительные дыры в систему. На практике вопрос может решаться для очень слабо защищённых программ (типа браузеров), безопасность которых пытаются достичь скрытием их в виртуальной машине. Если виртуальная машина предполагается много менее дырявой чем прикрываемое ей приложение/я, то "оптимизация риска" будет всё же в пользу использования виртуализации.
В свою очередь, Тео прав, потому что там речь шла о совсем другой ситуации: попытке увеличить безопасность итак одного из самых защищённых кусков системы (т.е. самой ОС) путём помещения её в менее безопасную виртуальную машину. К тому же речь шла скорее о защите в смысле взлома а не "утечек нежелательных данных".
Это просто заглушка, прослойка между почти всеми системными вызовами: разрешать или нет. Сама по себе она простая.
Концепт авторов: система безопасности ядра (Selinux) в идеале не может регулировать меньше действий, чем может совершать само ядро.
Сложность в создании правил компактного описания разрешений/запретов из-за сложности самого ядра.
Т.о. у DeRaadta есть простой концепт безопасности у Selinux — сложный, у виртуальных машин — вообще никакого, тут он прав.
Вобщем, сферических виртуалок в вакууме не существует.
У меня винда под виртуалкой орет, что ей нужен антивирус.
Мне что, ставить пропиетарный авирь на нее, или как?!
Можно и свободный поставить. Или отключить эти уведомления в Центре безопасности.
Саттва, так надо ставить или нет?!
И если ставить, какой свободный под винду порекомендуете?!
Я не сторонник антивирусов. Даже под Винду. Лучше в плане привилегий гайки затянуть.
А как их "затянуть" в виртуалке?!
Ну, понятное дело, пустить ее под отдельным пользователем под отдельными иксами, зачмодить все что можно таким образом, чтобы нельзя было до него добраться, и т.п.
Но это касается защиты физической машины. А например если я бабками или ценными бумагами распоряжаюсь из оси, установленной в вирт. машине, как мне защититься от троянов и прочей хрени?!
Затягивание гаек в винде.[link4]
Кстати, раз с виртуалками так все плохо, может есть какой-нибудь рейтинг по их защищенности?
Из более-менее приемлимых (открытый код, нормальная производительность) вижу только qemu-kvm и VirtualBox OSE, склоняюсь к qemu. В какую вообще сторону можно смотреть?
Под VB ряд ОСей глючит. qemu самая популярная и полностью эмулирует всё. Ещё есть гипервизоры (см. Xen), но ОС на них, как я понял, не будет скрывать то, на каком реальном железе она работает (гипервизор – способ запустить несколько ОСей на одном и том же железе одновременно без эмуляции, как я себе представляю; если це не критично, то оно лучше qemu, ибо сильно быстрее).