id: Гость   вход   регистрация
текущее время 17:23 28/03/2024
Автор темы: Гость, тема открыта 05/11/2013 12:07 Печать
Категории: анонимность
http://www.pgpru.com/Форум/UnixLike/ПортабельныйЗапускБраузеров
создать
просмотр
ссылки

Портабельный запуск браузеров


Форумчане, подскажите плиз, как сделать изолированный запуск браузеров под определенную анонимную сеть и связать их ярлыки. С ТОR все понятно – портабельную версию качаю, запускаю ярлык и одновременно запускается TBB, как такое-же сделать с I2P? чтобы запускался браузер и при этом соединения в обычные интернеты блокировалось на время работы I2P.
Спасибо


 
На страницу: 1, 2, 3, 4 След.
Комментарии
— Гость (11/11/2013 06:04)   <#>

когда вы открываете терминал, зловред может вместо него вывести собственное окошко, внешне выглядящее также, и перехватить все ваши пароли на sudo. Всё, что вы вводите, он может на лету транслировать в настоящий терминал, а сдампленные пароли или текст потом выслать себе домой по сети.


У людей сработало при настройках по умолчанию: раз, два, три, четыре. По последней ссылке:

Если в третьей команде делать не sudo -u user, а просто sudo, т.е. запускать xev от рута, то дырка заработает в обе стороны.

Изначально речь шла об использовании sudo для выполнения административных действий из-под якобы небезопасного обычного локального пользователя, под которым могут крутиться всякие браузеры и прочие опасные вещи. Вы хотите сказать, что если делать не sudo -u root или просто sudo, а sudo -u nonpriveleged_user, то способ с xev не будет работать?


Мы считаем, что зловред имеет все те же права, что и пользователь, от имени которого он запустился. Пусть для простоты это будет обычная учётная запись без особых привелегий. Чтобы переопределить $PATH, зловред меняет переменную $PATH в конфигах шелла (~/.bashrc), добавляя путь к какому-нибудь скрытому каталогу в той же директории. Была переменная
PATH=/sbin:/usr/sbin:итд
а стала
PATH=/home/USERNAME/.cache/ещё_что-нибудь/bin:/sbin:/usr/sbin:итд
В каталог /home/USERNAME/.cache/ещё_что-нибудь/bin зловред кладёт свой собственный троянский sudo, это может быть даже обычный скрипт. Теперь, если вы в терминале выполните sudo, будет выполнено не /bin/sudo (или где оно там лежит), а /home/USERNAME/.cache/ещё_что-нибудь/bin/sudo. Понятно, что так можно подменять любой исполнимый файл, включая сам шелл.

И, ещё раз повторяю, это просто демонстрационные примеры. Реальный хак может быть намного уменее и намного более скрытым, адаптированным к конкретным конфигам и программному окружению пользователя и т.д. Такое впечатление, что объясняю шарообразность Земли в детском саду.


А в su не включена. Ссылка на man su приведена в качестве пруфа.


Не обязательно, но процессы, запущенные от одного пользователя, имеют доступ к другим процессам, запущенным от этого же пользователя, их файлам и прочему, при этом не важно, под одними и теми же иксами всё это запущено или под десятью разными.


Для выполнения команд от рута — логиниться в консоли и выполнять их. Для выполнения команд от имени другого пользователя — логиниться в других иксах под именем этого пользователя и выполнять их там. Если иксы не нужны, можно воспользоваться текстовым терминалом.


В Linux можно надёжно выключить микрофон так, чтобы звук в наушниках работал, а микрофон нет? Если убрать юзера из audio, то пропадёт вообще всё.

Кстати, прослушивание по акустическому каналу вообще лёгкое, особенно на ноутбуках. Их корпус играет роль резонатора. Когда нажимаешь разные клавиши, это то же самое, как если стучишь по разным точкам резонатора — звук многих клавиш отличим обычным ухом, если прислушаться. Легко можно различать нажатия клавиш, принадлежащие разным рядам на клавиатуре, чётко слышны пробел и перевод строки. Зная заранее, какие команды может набирать пользователь, всё ещё сильней упрощается, даже тонкий анализ звука может не понадобиться.

Допустим, юзер переключился в текстовый терминал, чтобы зайти под рутом, вводит пароль, а в это время включен микрофон под другим пользователем — и всё, пароль прослушан. Вроде бы всеми ругаемое pulseaudio умело оперативно блокировать звуковой ввод/вывод, когда переключаешься в другого пользователя, но минусы pulseaduio с лихвой перевешивают всё остальное, поэтому нет ни малейшего желания его касаться.

Ещё один интересный вопрос — клавиши Ctrl+Alt+Fn для переключения. Если юзер скомпрометирован, может ли зловред, под ним запущенный, проинструктировать иксы иначе отреагировать на эту комбинацию? Например, вместо того, чтобы реально переключиться в другие иксы, вывести окошко на full screen, которое будет имитировать успешное переключение, а потом записать пароли, которые туда вводятся.
— Гость (09/03/2014 04:02)   <#>

С группой wheel достаточно забавная история. Вроде это зависит от дистра, где-то по умолчанию wheel есть и работает, где-то нет. Конкретно в Debian wheel нет, потому что когда Столлман лезет из идеологии своими грязными лапами в софт, получается говно и только говно (достаточно вспомнить, сколько его гнобили за выбор диалекта LISP'а для emacs'а). Полюбуйтесь:

23.6.1 Why GNU `su' does not support the `wheel' group


(This section is by Richard Stallman.)

Sometimes a few of the users try to hold total power over all the rest. For example, in 1984 [это намёк?], a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keeping it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.)

However, occasionally the rulers do tell someone. Under the usual `su' mechanism, once someone learns the root password who sympathizes with the ordinary users, he or she can tell the rest. The "wheel group" feature would make this impossible, and thus cement the power of the rulers.

I'm on the side of the masses, not that of the rulers. If you are used to supporting the bosses and sysadmins in whatever they do, you might find this idea strange at first.

Переводя на русский язык: 30 лет назад кисо обиделось, что ему не дали административный доступ, хотя оно знало пароль. Кисо отомстило, выпилив «злостную фичу» из TRUE-свободного дистрибутива Debian полностью. Теперь миллионы людей по всему миру десятилетия будут испытывать возможные трудности, зато лично его это устраивает. Чисто идеологическое решение. Хочешь исправить у себя лично — исправь вообще у всех, во всём мире. Супер-подход, очень гнуто.

Итак, в Debian любой пользователь из группы audio может включить микрофон, прослушать нажатия клавиш, узнать пароль root'а, повысить привелегии и потом узнать все пароли на крипторазделы (т.е. даже если пароли на крипторазделы не вводятся, когда что-то запущено с правами этих пользователей, это не поможет). Был бы wheel — он бы не дал пользователю воспользоваться этим паролем. Невольно вспоминается тот факт, что в OpenBSD по умолчанию пользователь не имеет никакого доступа к audio-системе.

На самом деле, есть GNU su и BSD su. Понятно, что в Debian ни о каком BSD su не может идти и речи. Правда, в какой-нибудь генте может быть и BSD su(?) [не проверял]. Кому сильно не хватает группы wheel, её можно вернуть на место, есть даже более гибкий механизм (см. /etc/pam.d/su):
# Uncomment the following line to require a user to be in the "wheel" group.
# auth           required        pam_wheel.so use_uid
Или вот (на другой системе):
# Uncomment this to force users to be a member of group root
# before they can use `su'. You can also add "group=foo"
# to the end of this line if you want to use a group other
# than the default "root" (but this may have side effect of
# denying "root" user, unless she's a member of "foo" or explicitly
# permitted earlier by e.g. "sufficient pam_rootok.so").
# (Replaces the `SU_WHEEL_ONLY' option from login.defs)
# auth       required   pam_wheel.so
 
# Uncomment this if you want wheel members to be able to
# su without a password.
# auth       sufficient pam_wheel.so trust
 
# Uncomment this if you want members of a specific group to not
# be allowed to use su at all.
# auth       required   pam_wheel.so deny group=nosu
Т.е. можно даже насоздавать какие-то другие группы с похожей функциональностью (не только wheel), и, если юзер не в них, то повышение привелегий не заработает.


Не получится. su — часть пакета login, который нужен. В свою очередь, login несуиден и не может быть запущен от обычного пользователя (от рута работает):
$ login
login: Cannot possibly work without effective root
$ ls -la /bin/login
-rwxr-xr-x 1 root root XXK XXX XX XXXX /bin/login*
Короче, лучше
# mv /bin/su /path/to/backup

Наверно, сугубо теоретически, покрутив правила udev, можно добиться, чтобы соответствующие устройства в /dev создавались без прав audio на что-либо, включая микрофон. Не экспериментировал.
— SATtva (09/03/2014 12:31)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
На самом деле, есть GNU su и BSD su. Понятно, что в Debian ни о каком BSD su не может идти и речи. Правда, в какой-нибудь генте может быть и BSD su(?) [не проверял].

Не знаю, чей тут su, но группа wheel на него влияет: для пользователей не из группы пароль суперюзера не принимается.
— Гость (09/03/2014 14:25)   <#>
Значит, не зря говорят, что у неё корни в BSD.
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3