Tor Browser Bundle и пакетный Tor
Имеется хост под Debian, на котором установлен пакет Tor и имеются несколько прозрачно торифицированных юзеров.
Установил tor-browser-bundle, запускаю под торифицированным юзером – запускается от юзера vidalla, tor и firefox.
Т.е., как я понимаю, tor локальный запускается внутри tor'а системного, что замедляет соединение.
При этом, в рассылке уже не рекомендуют пользоваться iceweasel + tor, а настоятельно рекомендуют переходить на browser bundle.
Но хочется запускать бразуер под прозрачно торифицированным юзером. Что делать?!
комментариев: 9796 документов: 488 редакций: 5664
Да они в последнее время совсем забили на продвинутых пользователей. Приходиться обо всё догадываться самим.
Возможен такой вариант. Оставить аккуратно настроенные системные Tor и Polipo (в зависимости от способа прозрачной торификации polipo м.б. не нужен и даже вреден). А для TorBrowser не запускать прилагаемый к нему скрипт, который стартует локальный тор, видалию и сам браузер. Лучше запускать непосредственно только ../tor-browser_en-US/App/Firefox/firefox.
Но перед этим, чтобы корректно работали поставляемые с браузером плагины (Torbutton, HTTPS-everywhere, NoScript), скопировать содержимое каталогов:
Ну, или тоже самое симлинками.
При этом как быть с видалией – неясно. Она в этом случае как-бы не нужна. И желания её настраивать, как лишнюю сущность, нет.
Хорошо бы конечно уточнить в рассылке, насколько корректно так делать, описав ситуацию (что нужно именно оставить системный Tor). Иначе можно получить отписку – пользуйтесь только стандартным способом по инструкции для чайников или ждите, пока начнут собирать tor-browser-пакеты для Debian, с учётом его специфики и конкретно случаев запуска tor'a в системе из ими же (разработчиками) поставляемого дебиановского tor-пакета, а не из под пользователя.
Но продвинутые тоже любят готовенькое по правилам, однако.
комментариев: 9796 документов: 488 редакций: 5664
https://lists.torproject.org/p.....-October/021706.html
Начиная с текущей версии 2.2.33-3, словно бы в ответ на наши пожелания, всё как будто нарочно поломали. Теперь TorBrowser из Bundle по-отдельности нормально уже не работает. При запуске напрямую он просто падает с ошибкой. При попытке закомментировать Видалию в скрипте и вписать туда запуск firefox-TB, он таки подхватывает большинство нужных параметров, стартует, не падает и работает. Ошибки при этом всё равно выводятся. Плагины при этом не работают (TB, HTTPS-everywhere, NoScript). Также он не подхватывает профиль Iceweasel, так что все накопленные в нём закладки не отображаются.
Работать с обычным (дефолтным) стартовым скриптом, как задумали авторы, можно. Но тогда трафик будет дважды заворачиваться в Tor при прозрачной торификации юзера и зверски тормозить. Также, tor будет стартовать с правами пользователя, а не как системный демон с ограниченными правами. Что плохо с точки зрения безопасности. Не говоря уже о том, что навесить на это стандартные правила SELinux становится совсем невозможно.
Пользователям придётся работать с TBB как есть, прозрачная торификация накрывается медным тазом. Можно конечно переколбашивать исходники, но поскольку там часто меняющаяся бета-версия, хотелось бы придумать что-то получше.
И судя по скупым/неохотным ответам разработчиков (одного пока), исправлять ситуацию они сами не будут. Людей/ресурсов на это нет и/или это не в приоритете. Как во всём opensource: что не устраивает — делайте сами, без шансов попасть в мэйнстрим. А для over-99% пользователей проще иметь простую готовую сборку, с готовыми настройками из-коробки, пусть и без чудес гибкости и параноидальных настроек безопасности. И вообще, пользователи по-умолчанию сидят под Виндой, которой отдаются приоритеты в плане разработки клиентской части.
А прозрачная торификация и отдельные tor-пакеты теперь похоже будут актуальны только для серверов.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 9796 документов: 488 редакций: 5664
Лучше действительно как-то по-простому соорудить это в VM. Но такой вариант torproject вообще не рассматривает и он даже не обсуждался в рассылке. Кстати и их вики и часть доков резко устарела — кое-где ещё описывается privoxy (впрочем как и у нас).
Официальная позиция торпроджекта видится опять же такой: непараноикам рекомендуется просто скачать TBB и использовать как есть одним кликом и не заморачиваться. Этого как-бы достаточно.
Любители попараноить и покрасноглазить могут пообсуждать свои наработки здесь. А то мы так тоже всех пользователей распугаем :)
Непонятен такой момент. Стартовый скрипт запускает видалию. Она настраивает локальный Tor, чекает коннект через него и запускает Aurora-Firefox-TorBrowser, передавая ему какие-то параметры. Если бы всё делалось только скриптом, то было бы проще. А так надо ещё в Видалию лезть.
И раз разработчики не хотят сами разделить всё по пакетам для Debian и др. систем, а пакуют только связкой и просить их об этом бесполезно, то может предложить им какую-то неумолчательную опцию в каком-нибудь конфиге, который бы проверялся стартовым скриптом — "использовать внешний Tor"?
Если вы про то, что под каждым торифицируемым юзером запускать Tor с его же правами — это дурная идея. Торифицируемый юзер — это одна сущность. Пользователь, под которым мы хотим запустить для него Tor — другая сущность. Дело в том, что нет простых способов, например на уровне firewall, контролировать куда идёт трафик от пользователя, под которым запущен Tor. Если выполняется злоумышленный код под таким юзером и патчится Tor-клиент, мы беспомощны, потому надо хотя бы разделять по юзерам как я выше сказал.
Не знаю как проще соорудить костыль, но можно вот так. Пусть из-под юзера всё запускается так, как запускается по умолчанию. Это должно работать по спецификации разработчиков. Далее, когда уже всё запустилось, мы глушим 9ым сигналом Tor, который был запущен под юзером, и запускаем уже свой Tor. из-под другого специального пользователя, и пропсываем его IP:порт в настройках TBB. Он съест такой трюк? Далее подгружаем правила pf/iptables и нужный нам юзер залочен так, как надо.
Если убийство Tor'а связка не переживёт, мы можем параллельно запустить второй Tor на других IP:порт и указать его связке когда она уже запустилась, а потом fw'ом закрыть трафик, идущий не на второй Tor.
Идея проста — второй Tor должен заэкранировать первый. Поскольку на одном host:port 2 сервиса не поднять, надо как-то хитрее, типо вышеописанного. В голове крутится идея наподобие работы рутинга: у нас есть 2 маршрута параллельно, оба дефолтные, но у них разные приоритеты. Вот так же бы и с Tor'ом сделать...
В самом крайнем случае проще и надёжней хакать не видалию, а именно сам Tor-клиент. Сделать так, чтобы его функционал был ограничен простым перенаправлением пакетов на нужный адрес. Можно даже скомпилить такой клиент из команды ssh -D, назвать его "Tor" и подсунуть в связку. Далее вывод с такого Tor-клиента-пустышки будет fw'ом перенаправляться в настоящий Tor, запущенный под другим юзером.
комментариев: 9796 документов: 488 редакций: 5664
В этой ветке смешнее, чем в теме Юмор и главное никакого оффтопика. Вот стоило написать в рассылку про желание запускать TB без связки и действительно, нарочно сделали.
А убийство Тора с Видалией после запуска как бы прокатывает, но она в торбатон прописывает каждый раз случайный порт socks-сервера, добавляя геммороя.
Также в торбатоне нельзя теперь поменять умолчательные установки на пункт "transparent firewalling" — он остался (вероятно, в качестве насмешки), но просто не выбирается.
Ну это тоже будет потенциально язвимый сетевой демон, запущенный с правами пользователя. Да и ещё и несущий больше лишнего функционала, чем сам Tor (доступ к шеллу, запись, исполнение команд). Или всё перекомпилировать до полной кастрации?
Это-то как раз не страшно. Firewall позаботится о том, чтобы в обход настоящего Tor'а он в сеть пройти не смог.
В принципе — да, но если мы рассматриваем как угрозу получение злоумышленником исполнение произвольного кода от имени Tor-пользователя, то он и так и так получает Т.е. от такого надо защищаться виртуалкой.
Ну если квалификации хватает :) Просто сделать вызов конкретной UNIX-команды из исходника на сях — это 10 строчек от силы на всё про всё, а кастрировать — тут уже понимание нужно. При необходимости ssh -D можно заменить любым простым легковесным socks-прокси.
комментариев: 9796 документов: 488 редакций: 5664
Также можно торифицировать содержимое виртуалки. И Tor с юзерскими правами не используется. А системный /etc/init.d/tor может запускаться только рутом, затем сбрасывает свои права и работает из-под пользователя debian-tor с ограниченными правами (например не имеет своего шелла и может быть придавлен SELinu'ксовскими правами).
Плюсы ещё в том, что ни одна из возможных ошибок не фатальна: если не убить юзерский tor, то трафик FF будет просто дважды заворачиваться в Tor-сеть и тупить с удвоенными цепочками; если забыть поменять порт в TorButton, то браузер напишет "не могу установить соединение".
Вот только думаю, стоит ли публиковать такой рецепт в рассылке или параноикам всё равно ничего не ответят, а опять устроят подлянку? Хотя, если конструктивно сформулировать, может будет больше пользы. Разработчики же не из вредности, а из-за компромиссов в сторону большинства делают свои изменения.
Имхо, стоит — хотя бы для того, чтобы показать разработчиком до какого абсурда приходится опускаться при отклонении от "генеральной линии партии".
комментариев: 9796 документов: 488 редакций: 5664
опубликовал. Спасибо всем, кто помогал в придумывании решения.
И не мы одни попадаем в этот абсурд: кто-то уже придумал решение похуже — перебить все права TBB на debian-tor и при этом по-ошибке одной командой
расшарил иксы на всю сеть и дал доступ также и всем программам со своего хоста (судя по адресу почты, может даже с Tor-узла). Epic fail!
Если разработчики не придумают нормальные, готовые, проверенные, обкатанные опции для unix-friendly использования, то будет не только абсурд, но и некоторое количество покалеченных самопальными решениями.