Портабельный запуск браузеров
Форумчане, подскажите плиз, как сделать изолированный запуск браузеров под определенную анонимную сеть и связать их ярлыки. С ТОR все понятно – портабельную версию качаю, запускаю ярлык и одновременно запускается TBB, как такое-же сделать с I2P? чтобы запускался браузер и при этом соединения в обычные интернеты блокировалось на время работы I2P.
Спасибо
У людей сработало при настройках по умолчанию: раз, два, три, четыре. По последней ссылке:
Изначально речь шла об использовании sudo для выполнения административных действий из-под якобы небезопасного обычного локального пользователя, под которым могут крутиться всякие браузеры и прочие опасные вещи. Вы хотите сказать, что если делать не sudo -u root или просто sudo, а sudo -u nonpriveleged_user, то способ с xev не будет работать?
Мы считаем, что зловред имеет все те же права, что и пользователь, от имени которого он запустился. Пусть для простоты это будет обычная учётная запись без особых привелегий. Чтобы переопределить $PATH, зловред меняет переменную $PATH в конфигах шелла (~/.bashrc), добавляя путь к какому-нибудь скрытому каталогу в той же директории. Была переменная
И, ещё раз повторяю, это просто демонстрационные примеры. Реальный хак может быть намного уменее и намного более скрытым, адаптированным к конкретным конфигам и программному окружению пользователя и т.д. Такое впечатление, что объясняю шарообразность Земли в детском саду.
А в su не включена. Ссылка на man su приведена в качестве пруфа.
Не обязательно, но процессы, запущенные от одного пользователя, имеют доступ к другим процессам, запущенным от этого же пользователя, их файлам и прочему, при этом не важно, под одними и теми же иксами всё это запущено или под десятью разными.
Для выполнения команд от рута — логиниться в консоли и выполнять их. Для выполнения команд от имени другого пользователя — логиниться в других иксах под именем этого пользователя и выполнять их там. Если иксы не нужны, можно воспользоваться текстовым терминалом.
В Linux можно надёжно выключить микрофон так, чтобы звук в наушниках работал, а микрофон нет? Если убрать юзера из audio, то пропадёт вообще всё.
Кстати, прослушивание по акустическому каналу вообще лёгкое, особенно на ноутбуках. Их корпус играет роль резонатора. Когда нажимаешь разные клавиши, это то же самое, как если стучишь по разным точкам резонатора — звук многих клавиш отличим обычным ухом, если прислушаться. Легко можно различать нажатия клавиш, принадлежащие разным рядам на клавиатуре, чётко слышны пробел и перевод строки. Зная заранее, какие команды может набирать пользователь, всё ещё сильней упрощается, даже тонкий анализ звука может не понадобиться.
Допустим, юзер переключился в текстовый терминал, чтобы зайти под рутом, вводит пароль, а в это время включен микрофон под другим пользователем — и всё, пароль прослушан. Вроде бы всеми ругаемое pulseaudio умело оперативно блокировать звуковой ввод/вывод, когда переключаешься в другого пользователя, но минусы pulseaduio с лихвой перевешивают всё остальное, поэтому нет ни малейшего желания его касаться.
Ещё один интересный вопрос — клавиши Ctrl+Alt+Fn для переключения. Если юзер скомпрометирован, может ли зловред, под ним запущенный, проинструктировать иксы иначе отреагировать на эту комбинацию? Например, вместо того, чтобы реально переключиться в другие иксы, вывести окошко на full screen, которое будет имитировать успешное переключение, а потом записать пароли, которые туда вводятся.
С группой wheel достаточно забавная история. Вроде это зависит от дистра, где-то по умолчанию wheel есть и работает, где-то нет. Конкретно в Debian wheel нет, потому что когда Столлман лезет из идеологии своими грязными лапами в софт, получается говно и только говно (достаточно вспомнить, сколько его гнобили за выбор диалекта LISP'а для emacs'а). Полюбуйтесь:
Переводя на русский язык: 30 лет назад кисо обиделось, что ему не дали административный доступ, хотя оно знало пароль. Кисо отомстило, выпилив «злостную фичу» из TRUE-свободного дистрибутива Debian полностью. Теперь миллионы людей по всему миру десятилетия будут испытывать возможные трудности, зато лично его это устраивает. Чисто идеологическое решение. Хочешь исправить у себя лично — исправь вообще у всех, во всём мире. Супер-подход, очень гнуто.
Итак, в Debian любой пользователь из группы audio может включить микрофон, прослушать нажатия клавиш, узнать пароль root'а, повысить привелегии и потом узнать все пароли на крипторазделы (т.е. даже если пароли на крипторазделы не вводятся, когда что-то запущено с правами этих пользователей, это не поможет). Был бы wheel — он бы не дал пользователю воспользоваться этим паролем. Невольно вспоминается тот факт, что в OpenBSD по умолчанию пользователь не имеет никакого доступа к audio-системе.
На самом деле, есть GNU su и BSD su. Понятно, что в Debian ни о каком BSD su не может идти и речи. Правда, в какой-нибудь генте может быть и BSD su(?) [не проверял]. Кому сильно не хватает группы wheel, её можно вернуть на место, есть даже более гибкий механизм (см. /etc/pam.d/su):
Не получится. su — часть пакета login, который нужен. В свою очередь, login несуиден и не может быть запущен от обычного пользователя (от рута работает):
Наверно, сугубо теоретически, покрутив правила udev, можно добиться, чтобы соответствующие устройства в /dev создавались без прав audio на что-либо, включая микрофон. Не экспериментировал.
комментариев: 11558 документов: 1036 редакций: 4118
Не знаю, чей тут su, но группа wheel на него влияет: для пользователей не из группы пароль суперюзера не принимается.