Портабельный запуск браузеров
Форумчане, подскажите плиз, как сделать изолированный запуск браузеров под определенную анонимную сеть и связать их ярлыки. С ТОR все понятно – портабельную версию качаю, запускаю ярлык и одновременно запускается TBB, как такое-же сделать с I2P? чтобы запускался браузер и при этом соединения в обычные интернеты блокировалось на время работы I2P.
Спасибо
Любая программа может обращаться к Х серверу, который доступен по-видимому через порт или unix-сокет. Другое дело что не в каждой программе реализован интерфейс для этого.
комментариев: 1060 документов: 16 редакций: 32
Резюмируя всё вышесказанное: если некоторая программа получила доступ к дисплею X, то она сможет прослушать события в любом открытом на том дисплее окне. К sudo это строго говоря непосредственного отношения не имеет, просто многие думают, что если процессы двух разных пользователей используют один и тот же дисплей, то один не сможет читать события другого, а это не так, сможет.
комментариев: 9796 документов: 488 редакций: 5664
Экплойт в браузере + xhost = Х сервер выполняет роль трояна выдающего все действия с оборудованием.
комментариев: 9796 документов: 488 редакций: 5664
Можете расшарить скорее теоретически. На практике во всех дистрах иксы запускаются по умолчанию с опцией --no-listentcp. Чтобы её поменять, понадобится доступ к конфигу с правами рута.
В итоге выходит что нападки на sudo ничем не обоснованы, связаны с недостаточным пониманием работы X-сервера.
Пруф:
Сколько я видел мануалов в интернете по зачрутовыванию разных программ, и нигде не прослеживалась универсальность. В частности, мануал по зачрутовыванию Tor в, кажется, OpenBSD напоминал адский набор сотен грязных хаков.
Неизбежная плата за безопасность.
Ещё раз: ни chroot, ни AppArmor не дают обоснованной безопасности. Единственный более-менее обоснованный способ защиты от всех видов атак — SELinux.
Эти допущения нарушают принцип Керхгоффса. Они из той же степи, что и «а давайте не будем монтировать системные разделы». Вломщик весь необходимый ему софт может доставить самостоятельно, прав у него будет достаточно. Заведомо полагаться, что он откажется от этой затеи, глупо.
Вы видите выше написано Ваш файерволл обходится на раз, если заблочивание юзера ограничилось вами приведёнными (или им подобными) правилами. Подумайте, почему.
Не нужна. Пример с xev был не более, чем красочной демонстрацией. На самом деле, нет и не может быть доверия ни к чему, что запускается от потенциально скомпрометированного пользователя. Например, когда вы открываете терминал, зловред может вместо него вывести собственное окошко, внешне выглядящее также, и перехватить все ваши пароли на sudo. Всё, что вы вводите, он может на лету транслировать в настоящий терминал, а сдампленные пароли или текст потом выслать себе домой по сети.
sudo в текстовом терминале тоже небезопасно. Там есть свои методы, как подцепиться к уже открытой sudo сессии, как накормить жертву нужными переменными среды, которые подменят исполнимые файлы или подгружаемые библиотеки, и т.д. Если юзер считается потенциально скомпрометированным, то не важно, под иксами он или в текстовом терминале — зловред всегда может найти способ повысить свои привелегии до тех, до которых может дотянуться жертва.
+1
Даёт (см. объяснения выше). Для начала, условимся считать, что ничего графического из-под su/sudo/ssh мы не запускаем. Если запускаем консольные программы под su/sudo/ssh, то всю деятельность можно прологировать, а пароли на su/sudo/ssh украсть. В случае же отдельного X-сервера чтобы что-то украть или прологировать, нужно одновременное осуществление двух событий:
Архитектура X-сервера уязвима, протокол запутан, его мало кто понимает, в самом X-сервере дыр находили меряно-немеряно, и неизвестно, сколько ещё найдут. Это одна из причин, по которой X-сервер настоятельно рекомендуется не ставить на сервера.
sudo — идеологическое зло, потому что создаёт у пользователя иллюзию, что это средство безопасности. Но это не средство безопасности точно так же, как noexec или chroot!
Use case для sudo — это когда вы одинаково доверяете обоим пользователям (тому, из под которого запускаете sudo, и тому, чьи права желаете получить), и хотите получить права одного из-под другого удобным образом. Это относится к компиляциям, сборкам дистров и т.д. И chroot в этих случаях тоже по назначению используется. Но если хоть к одному из юзеров нет доверия, вся эта архитектура моментально рушится, эти средства никогда не предназначались для повышения безопасности, об этом даже в man написано.
P.S.:
- Запуск программ под отдельным X-сервером со своим логином — тоже не панацея. Если уязвимый пользователь — член группы audio, то никто не запрещает ему включить микрофон и прослушивать по акустическому каналу все нажатия клавиш, которые вы нажимаете, будучи в других иксах, текстовых терминалах и т.д. В частности, пароли на крипторазделы по такому side channel утекают только так.
- И виртуалки тоже не панацея, т.к. запуск зловреда в одной виртуальной ОС позволяет украсть ключи, использумые в другой виртуальной ОС.
- И отдельные компьютеры тоже не панацея, т.к. по акустическому, электромагнитному и др. side channels всё равно утекает много чего.
По-хорошему, для каждой задачи нужен свой отдельный компьютер, находящийся в своём отдельном бункере с полной изоляцией. И без сети, да. SATtva, я всё правильно сказал?Уже три. Третий не настолько универсален, но на очень многих конфигурациях сработает.
Кто назовёт все три, получит пирожок.комментариев: 11558 документов: 1036 редакций: 4118
Например? По умолчанию sudo не допускает передачу произвольных переменных в исполняемые приложения: man sudoers / Command environment.
В предельном случае — да.
Это про su было:
Из man su:
Т.е. если вы не указали «-», то environment берётся от текущего юзера, который, если скомпрометирован, может передать, к примеру, «правильные» PATH в новый шелл под рутом. Хотел ещё и man sudo посмотреть на этот счёт, но
Ещё варанты:
Как пример: был файл на файловой системе, но мы его удалили, а программа его ещё использует. Казалось бы, задача найти файл и посмотреть, что в нём, сохранить его куда-нибудь — нерешаемая, а реально lsof + /proc делают такую операцию штатной возможностью (находится дескриптор файла, инод его, потом делается несколько команд; детали не помню, но знаю, что делается). С tty могут быть извраты того же уровня.
Вариант 2 универсален. Он работает всегда. Этого достаточно, чтобы сказать, что под скомпрометированным пользователем доверять нельзя ничему.
комментариев: 11558 документов: 1036 редакций: 4118
Справедливо.
Для каждой программы нужен свой скрипт, универсального нет. Имелось в виду что создав скрипт, можно потом долго им пользоваться, как и конфигурационным файлом. Способы создания песочницы для однотипных программ, типа сетевых серверов, очень похожи.
Не знаю что за принцип Керхгоффса, но задачу взломщику это усложнит, потребует более высокой квалификации и большей затраты времени. Т.е. взлом будет дороже, значит система безопасней, т.к. уровень безопасности определяется уровнем затрат атакующего. Безопасность это прежде всего экономика. А если повышенной квалификации и времени нет, то этот барьер не будет пройден и взлом не состоится.
Подтвердите это примером, чтобы не было как с sudo, когда в результате выяснилось что заявленная угроза в действительности не работает при найстройках по умолчанию и требует явного разрешения.
Тоже хотелось бы увидеть пример. По умолчанию в sudo включена опция env_reset, интересно как вы с ней справитесь.
Журналы событий типа /var/log/messages /var/log/secure доступны для чтения только руту, а как украсть пароль из терминала другого пользователя вы пока не продемонстрировали.
Чтобы запустить ещё один Х-сервер не обязательно создавать учётную запись, выше об этом уже написано.
sudo это удобный и настраиваемый способ запуска программ от разных пользователей. Не средство безопасности, а инструмент для построения относительно безопасных систем. И неясно что вы предлагаете взамен sudo.
В sudo есть опция secure_path, которая по умолчанию включена, и эта угроза не работает.
Запись в каталоги $PATH доступна только для рута, а подменить $PATH у другого пользователя зловред тоже не может если он не рут. Если имеется в виду запуск sudo в учётной записи, от которой разоботает программа поражённая зловредом, то это ещё один минус создания учётной записи. Когда её нет, то такого не произойдёт, зловред получает переменную $PATH от других программ, но сам никому её не передаёт.