Tor под виртуальной машиной
Установил virtualbox под Линуксом (т.к. мне нужна для винда для работы определенных программ).
Программы сетевые, хочу их заторить.
Соответственно, у меня после установки винды соединения из виртуальной машины шли незаторенные. (На линуксе стоит тор, но выхожу в инет и через тор, и не через тор, заториваю отдельные приложения).
Соответственно, установил в вирт. машине пакет tor-vidalla-privoxy для винды, удалось установить заторенное соединение.
Как при такой схеме все-таки лучше торить, черз тор-клиент, поднятый в вирт. машине, или через тор-клиент физической машины? И как в последнем случае торить?
P. S. И еще. Кто-то может описать, чем лучше для повышения анонимности выходить в Сеть через тор с виртмашины?! (Это не для того случая, где винда, для общих целей я лучше установлю еще одну линуху под вирт. машиной).
Может ли, например, включенный J при таком подключении украсть внешний ip, как он это делает в случае с физической машиной? Или он украдет "внешний" ip, который будет тождественен с внутренним ip физической машины?!
комментариев: 155 документов: 20 редакций: 5
комментариев: 155 документов: 20 редакций: 5
P. S. Вроде всегда считалось, что наоборот, нет угроз для физической машины, если юзать вирт.
2. И что мне теперь, на виртуалку устанавливать антивирус и пропиетарный фаервол?! (Я ей собираюсь, в т.ч., для финансовых целей пользоваться, т.к. у меня не все терминалы банкингов под линухой пашут).
комментариев: 9796 документов: 488 редакций: 5664
Мне в голову некогда приходила вот такая анология, не знаю насколько уместная. Допустим, что мы хотим построить кирпичный дом с непроницаемыми стенами, но в силу неидеальностей большинство используемых кирпичей имеют сквозные, случайно расположенные, отверстия. Можно использовать две стратегии: либо тщательно отбирать кирпичи и перепроверять их на наличие отверстий (OpenBSD), что позволяет делать более тонкие (простые) непроницаемые стены, либо не заботиться о качестве кирпичей, но делать кладку потолще, снижая вероятность появления сквозного отверстия сквозь всю стену (SeLinux). Т.о., во втором подходе "дыры закрываются другими дырами" в почти буквальном смысле, но есть надежда на то, что "вероятность критического дыросовпадения мала". Естественно, оба подхода неидеальны, оба имеют свои преимущества и недостатки, а реальное развитие вещей идёт в рамках обеих подходов. В частности, kauth в NetBSD и systrace в OpenBSD есть упрощёные аналоги SeLinux'а (впрочем, на systrace, судя по всему, подзабили). Равно и упрощение/оптимизация кода/интерфейсов в Linux есть суть первый подход.
комментариев: 9796 документов: 488 редакций: 5664
Проблемы тут такие:
1) правил может быть очень много и не получиться компактного описания в виде ясной политики
2) нужно досконально знать потроха системы и работающей программы
3) когда нужно выдать разрешение только на те действия, которые необходимы, можно ошибиться и разрешить лишние – пропустим дыру, если не допустить нужные — получим глюки программы.
4) если дыры окажутся в разрешённых действиях, то Selinux не поможет
5) дыры могут быть в самом Selinux
6) Модель Selinux может быть неполна (не все типы действий можно ограничить, хотя Selinux — максимально полная модель, стремящаяся регулировать всё, на что способно ядро).
Почему же неверна? Насколько я знаю, SeLinux – некий кусок ядра, т.е. дыры остальных программ/систем пытаются закрыть довлеющим над оными дополнительным куском кода, потенциально могущем иметь те же проблемы что и код, им защищаемый. Т.е. дело не только в том, что от каких-то дыр он может не спасти, но и в том, что (не в последнюю очередь из-за своей сложности) может внести совершенно новые, каких раньше не было.
В свою очередь, Тео прав, потому что там речь шла о совсем другой ситуации: попытке увеличить безопасность итак одного из самых защищённых кусков системы (т.е. самой ОС) путём помещения её в менее безопасную виртуальную машину. К тому же речь шла скорее о защите в смысле взлома а не "утечек нежелательных данных".
комментариев: 9796 документов: 488 редакций: 5664
Концепт авторов: система безопасности ядра (Selinux) в идеале не может регулировать меньше действий, чем может совершать само ядро.
Сложность в создании правил компактного описания разрешений/запретов из-за сложности самого ядра.
Т.о. у DeRaadta есть простой концепт безопасности у Selinux — сложный, у виртуальных машин — вообще никакого, тут он прав.
Мне что, ставить пропиетарный авирь на нее, или как?!
комментариев: 11558 документов: 1036 редакций: 4118