РегистрацияПортабельный запуск браузеров
Форумчане, подскажите плиз, как сделать изолированный запуск браузеров под определенную анонимную сеть и связать их ярлыки. С ТОR все понятно – портабельную версию качаю, запускаю ярлык и одновременно запускается TBB, как такое-же сделать с I2P? чтобы запускался браузер и при этом соединения в обычные интернеты блокировалось на время работы I2P.
Спасибо
Напомнинаю, что
Для каждого приложения желательно создать (man useradd) 2 пользователя: tor и toruser.** Для начала, пусть это будут обычные пользователи с шеллом. Tor запускаете из-под рута от имени, допустим, пользователя toruser. Если у вас автоматически создался нужный системный пользователь при установке Tor, можете попытаться использовать его. В иксах логинитесь от имени пользователя tor и настраиваете TBB на работу через тот Tor, который запущен от имени toruser. Потом сверху прикрываете всё файерволлом. Без знания iptables и специфики Linux вы это не настроите (разве что по готовому пошаговому мануалу, который никто вам писать здесь не будет, уж извините).
*Это правда, что su в Debian Linux работает искоробки для всех пользователей? Я по своей наивности думал, что если юзер не внесён в группу wheel (или какую-то другую, особую), то su не сработает. И, кстати, какие ограничения в Linux на запуск login?
**Имена взяты от балды. Можете назвать как-то по-другому.
Повторил ваш пример из ссылки для sudo вместо ssh
Т.е. запуск через sudo от другого пользователя не позволяет ему получить информацию о событиях из моего окна. Если не согласны, то приведите рабочий пример. К тому же Тор, прокси и прочие фоновые сетевые приложения можно запускать на этапе загрузки, до запуска Х сервера. Отдельная учётная запись для таких приложений хуже чем chroot, т.к. в случае уязвимости атакующий получает доступ ко всем программам в системе, что облегчает проникновение. Для chroot это не так, доступно только то что необходимо для работы защищаемого приложения, т.е. почти ничего.
Наиболее концептуально правильным является наверное Qubes, где изоляция не на уровне ядра, а ниже – на уровне гипервизора. К тому же сделать безопасным тонкий "гипервизор" (вернее – его часть отвечающую за изоляцию) гораздо легче, чем "толстое" ядро.
А что особенно сложного?
Чем не устраивает rm /bin/su? Только непонятно, чем он мешает, может и правда что-нибудь перестать работать. su (как и sudo) хорош в скриптах, запущенных от рута, в которых например нужно что-нибудь скачать из сети. В сеть лучше выходить от другого пользователя.
комментариев: 1060 документов: 16 редакций: 32
Я так понял, что в вашем случае запуск через sudo от другого пользователя не позволил получить доступ к дисплею, т.е. программа даже не сможет окно отобразить. Было бы интереснее это исправить уж тогда проверять.
У кого-то работает, у кого-то нет. Здесь специалистов по X-серверам нет, которые бы понятно разложили по полочкам, из-за чего работает, из-за чего нет, насколько надёжно можно заблокировать, нет ли других подводных камней? Тогда лучше этим не пользоваться. Я исхожу из того, что всё, что набирается на клавиатуре после логина в конкретного пользователя, ему доступно.
По ссылке разъяснено предельно подробно, причём неоднократно. Если вы всё внимательно прочитали, досконально проверили (а, судя по вашим объяснениям, вы делаете не в лоб то, что написано в примерах) и не взлетело, то помочь ничем не могу.
Это уловки. Я считаю всё, что находится в /home/anonymous_user, заведомо скомпрометированным, включая стартовые скрипты, например. Я не могу доверять ни одному файлу из этой директории за исключением тех текстовых, содержимое которых проверяется вручную перед запуском чего бы то ни было от имени этого пользователя.
chroot не сделает хуже, не спорю, но методов выхода из chroot миллион, поэтому надеяться на него серьёзно не стоит. С учётом того, как много гемора требует его настройка, я лично считаю, что овчинка не стоит выделки.
В легитимном режиме, ага. Но мы же речь не о нём ведём? В легитимном режиме и браузер ничего в обход прокси не шлёт, но файерволл вы же зачем-то настраиваете.
Ваш пример красочно отвечает на этот вопрос. Знаю минимум 2 рабочих универсальных метода обхода файерволла, настройка которого ограничилась этими правилами. Предлагаю вам догадать об этом самому.
Помимо этого: если после старта системы её глюканёт и интерфейс определится, как ppp1, то ничего ведь, правда? Ну, или если DHCP-сервер решит вам намного помочь... лень анализировать всё сценарии, но на DHCP я не полагаюсь.
Грязно. Если su ассицооирован с каким-то пакетом, то лучше сделать apt-get remove этот_пакет.
и кто сказал что в Линукс проще запустить приложение от другого пользователя, чем в Винде..?
в Винде 2-мя кнопками, здесь же... ну даже нет единого мнения как это реализовать. другими словами, проще чем гипервизор не вижу реализаций изолировать пользователей по задачам.
Вопрос же не в том, что где-то проще или тяжелее, а в том, как это сделать безопасным образом. Думаете, в винде это сделать безопасным образом проще? Там файерволлы вообще не умеют фильтровать по юзерам, если что, так что стадия с разделением пользователей пропадает, настройку придётся сразу начинать с виртуалки.
комментариев: 9796 документов: 488 редакций: 5664
man xhost не просветляет? echo $DISPLAY ничего странного не показывает?
комментариев: 1060 документов: 16 редакций: 32
В ламерской убунте ваши команды тоже не работают. Могу подсказать. Если в третьей команде делать не sudo -u user, а просто sudo, т.е. запускать xev от рута, то дырка заработает в обе стороны. Выхлоп xhost вполне объясняет, почему у вас не работает, к дисплею $DISPLAY можно цепляться только одному пользователю. С такой конфигурацией вообще нельзя запустить оконное приложение от имени другого пользователя под тем же X (кроме рута, разумеется)
Я же написал, что xev -id 0xXXXXXXX у меня работает, а с sudo от другого пользователя – нет (sudo от моего пользователя тоже работает).
Тогда лучше не делать категорических утверждений.
Пример с sudo отсутствует.
Если один раз во всём разобраться и оформить в виде скрипта для создания песочницы, никаких сложностей в дальнейшем нет. Запуск init-скрипта ничем не отличается. А вот переход из одной учётной записи в другую заметно снижает удобство пользователя. Пробовал оба способа – смена логина и chroot, так есть с чем сравнивать. По "юзабилити" и безопасности преимущество за chroot.
Речь шла о том, что вломщик имеет доступ ко всем утилитам системы, что может использовать для облегчения своей работы. Из chroot это всё недоступно, поэтому приходится использовать низкоуровневые средства.
У меня несколько другие настройки и dhcp сервера нет. Это был просто пример, который работает почти всегда (если указать нужный сетевой интерфейс).
комментариев: 1060 документов: 16 редакций: 32
Несколько опрометчиво считать некоторую систему безопасной при отсутствии доказательств уязвимости, вы не находите?
А у вас вообще запускаются программы в иксах от имени другого пользователя?
Предлагаю не приписывать мне утверждений, которых не делал.
В этом вы правы, не запускаются. После команды xhost + стали запускаться, sudo с xev от другого пользователя тоже заработало. В общем выходит, что для реализации "угрозы" от sudo пользователь должен явно разрешить доступ к своей графической среде, понимая связанные с этим риски. По умолчанию sudo в этом плане безопасно, кейлогер и монитор экрана от другого пользователя так просто работать не будут. Для этого нужна уязвимость в Х сервере, т.к. он управляет контролем доступа к графическим средам.
комментариев: 1060 документов: 16 редакций: 32
Небезопасно запускать программы от судо, если они имеют доступ к иксам – вот такой должен быть вывод. Собственно, это и говорилось ранее.
комментариев: 1060 документов: 16 редакций: 32