Для большей безопасности можно для каждого сетевого приложения, участвующего в анонимных соединениях, создать свой chroot – Тор, i2p, прокси (если есть), браузер.

распишите пожалуйста подробнее о создании пользователей под TOR\I2P

chroot^[link4] не предназначен для безопасности. Он никогда не создавался для этой цели. Разработчики торпроджекта, судя по их комментам в рассылке, даже не в курсе этого.

а вот в Линукс нет такой реализации.

1. sudo не обеспечивает^[link6] нужного уровня безопасности. Не пользуйтесь им. Не пользуйтесь даже su. Отдельный юзер — отдельный логин в графической среде (отдельных иксах) или в отдельный консоли.^*
2. chroot — то же самое. Unknown дал ссылку.

sudo не обеспечивает нужного уровня безопасности. Не пользуйтесь им. Не пользуйтесь даже su. Отдельный юзер — отдельный логин в графической среде (отдельных иксах) или в отдельный консоли.*

Без знания iptables и специфики Linux вы это не настроите

как его удалить из системы

Т.е. запуск через sudo от другого пользователя не позволяет ему получить информацию о событиях из моего окна.

Здесь специалистов по X-серверам нет, которые бы понятно разложили по полочкам, из-за чего работает, из-за чего нет, насколько надёжно можно заблокировать

а на других системах работает.

В ламерской убунте ваши команды тоже не работают. Могу подсказать. Если в третьей команде делать не sudo -u user, а просто sudo, т.е. запускать xev от рута, то дырка заработает в обе стороны. Выхлоп xhost вполне объясняет, почему у вас не работает, к дисплею $DISPLAY можно цепляться только одному пользователю. С такой конфигурацией вообще нельзя запустить оконное приложение от имени другого пользователя под тем же X (кроме рута, разумеется)

У кого-то работает, у кого-то нет

Здесь специалистов по X-серверам нет, которые бы понятно разложили по полочкам, из-за чего работает, из-за чего нет, насколько надёжно можно заблокировать, нет ли других подводных камней

По ссылке разъяснено предельно подробно, причём неоднократно.

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

> Для chroot это не так, доступно только то что необходимо для работы защищаемого приложения, т.е. почти ничего.

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

Ваш пример красочно отвечает на этот вопрос. Знаю минимум 2 рабочих универсальных метода обхода файерволла, настройка которого ограничилась этими правилами. Предлагаю вам догадать об этом самому.

Помимо этого: если после старта системы её глюканёт и интерфейс определится, как ppp1, то ничего ведь, правда? Ну, или если DHCP-сервер решит вам намного помочь... лень анализировать всё сценарии, но на DHCP я не полагаюсь.

Пример с sudo отсутствует.

Несколько опрометчиво считать некоторую систему безопасной при отсутствии доказательств уязвимости, вы не находите?

а с sudo от другого пользователя – нет (sudo от моего пользователя тоже работает).

А у вас вообще запускаются программы в иксах от имени другого пользователя?

Несколько опрометчиво считать некоторую систему безопасной при отсутствии доказательств уязвимости, вы не находите?

А у вас вообще запускаются программы в иксах от имени другого пользователя?

Небезопасно запускать программы от судо, если они имеют доступ к иксам – вот такой должен быть вывод.

Любая программа может обращаться к Х серверу, который доступен по-видимому через порт или unix-сокет.

Через xhost вы можете расшарить свои иксы на весь инет для беспарольного доступа. Это фича такая.

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

С xhost уже начинали^[link10], были предупреждения^[link11] и epic fail^[link12]. Я бы не стал xhost советовать.

Помимо этого?

Несколько опрометчиво считать некоторую систему безопасной при отсутствии доказательств уязвимости, вы не находите?

1. X-сервер запущен от рута (сейчас это почти везде так, к сожалению, хотя исключения бывают).
2. В X-сервере есть уязвимость (иксы — одна из самых дырявых программ, да).

не более чем средство например что-то скомпилировать или отладить под другую архитектуру, но это средство не имеет никакого отношения к безопасности.

1. Запуск программ под отдельным X-сервером со своим логином — тоже не панацея. Если уязвимый пользователь — член группы audio, то никто не запрещает ему включить микрофон и прослушивать по акустическому каналу^[link16] все нажатия клавиш^[link17], которые вы нажимаете, будучи в других иксах, текстовых терминалах и т.д. В частности, пароли на крипторазделы по такому side channel утекают только так.
2. И виртуалки тоже не панацея, т.к. запуск зловреда в одной виртуальной ОС позволяет украсть ключи, использумые в другой виртуальной ОС.
3. И отдельные компьютеры тоже не панацея, т.к. по акустическому^[link18], электромагнитному^[link19] и др. side channels всё равно утекает много чего^[link20].

sudo в текстовом терминале тоже небезопасно. Там есть свои методы, как подцепиться к уже открытой sudo сессии, как накормить жертву нужными переменными среды, которые подменят исполнимые файлы или подгружаемые библиотеки, и т.д.

По-хорошему, для каждой задачи нужен свой отдельный компьютер, находящийся в своём отдельном бункере с полной изоляцией. И без сети, да. SATtva, я всё правильно сказал?

Чтобы этого избежать, советуют писать su -l username или su -- (не помню, один там минус или два должно быть).

The optional argument – may be used to provide an environment similar to what the user would expect had the user logged in directly.

$ man sudo
No manual entry for sudo
$ sudo
SHELL: sudo: command not found

1. Eсли su/sudo запускается в терминальном мультплексоре (screen или tmux), то зловред может приаттачить открытую сессию к своему терминалу и выполнить в нём всё, что захочет.
2. Зловред может подменить su/sudo (и вообще любую команду) на свою собственую, протрояненную. Если профиль полностью скомпрометирован, это можно сделать через, например, переопределение переменной $PATH.
3. Вроде можно работать с терминалом, как с виртуальным устройством /dev/ttyN. Если прав на доступ к терминалу хватает (см., например, ls -la /dev/pts/1), т.е. терминал запущен от того же пользователя, вроде как можно перехватить управление им. Детали не знаю, т.к. не взломщик, а в этом в основном они разбираются. Кажется, в каких-то старых тредах лора показывали выкрутасы на эту тему. На 100% не поручусь.
   
   Как пример: был файл на файловой системе, но мы его удалили, а программа его ещё использует. Казалось бы, задача найти файл и посмотреть, что в нём, сохранить его куда-нибудь — нерешаемая, а реально lsof + /proc делают такую операцию штатной возможностью (находится дескриптор файла, инод его, потом делается несколько команд; детали не помню, но знаю, что делается). С tty могут быть извраты того же уровня.

Сколько я видел мануалов в интернете по зачрутовыванию разных программ, и нигде не прослеживалась универсальность. В частности, мануал по зачрутовыванию Tor в, кажется, OpenBSD напоминал адский набор сотен грязных хаков.

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

Эти допущения нарушают принцип Керхгоффса. Они из той же степи, что и «а давайте не будем монтировать системные разделы». Вломщик весь необходимый ему софт может доставить самостоятельно, прав у него будет достаточно. Заведомо полагаться, что он откажется от этой затеи, глупо.

> По умолчанию sudo в этом плане безопасно, кейлогер и монитор экрана от другого пользователя так просто работать не будут. Для этого нужна уязвимость в Х сервере, т.к. он управляет контролем доступа к графическим средам.

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

sudo в текстовом терминале тоже небезопасно. Там есть свои методы, как подцепиться к уже открытой sudo сессии, как накормить жертву нужными переменными среды, которые подменят исполнимые файлы или подгружаемые библиотеки, и т.д. Если юзер считается потенциально скомпрометированным, то не важно, под иксами он или в текстовом терминале — зловред всегда может найти способ повысить свои привелегии до тех, до которых может дотянуться жертва.

> Создание учётной записи не даёт никаких преимуществ перед sudo, только лишние действия.

Даёт (см. объяснения выше). Для начала, условимся считать, что ничего графического из-под su/sudo/ssh мы не запускаем. Если запускаем консольные программы под su/sudo/ssh, то всю деятельность можно прологировать, а пароли на su/sudo/ssh украсть.

В случае же отдельного X-сервера чтобы что-то украть или прологировать, нужно одновременное осуществление двух событий:

sudo — идеологическое зло, потому что создаёт у пользователя иллюзию, что это средство безопасности.

Т.е. если вы не указали «-», то environment берётся от текущего юзера, который, если скомпрометирован, может передать, к примеру, «правильные» PATH в новый шелл под рутом. Хотел ещё и man sudo посмотреть на этот счёт, но

Зловред может подменить su/sudo (и вообще любую команду) на свою собственую, протрояненную. Если профиль полностью скомпрометирован, это можно сделать через, например, переопределение переменной $PATH.

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

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

PATH=/sbin:/usr/sbin:итд

PATH=/home/USERNAME/.cache/ещё_что-нибудь/bin:/sbin:/usr/sbin:итд

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.

# 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

$ 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

На самом деле, есть GNU su и BSD su. Понятно, что в Debian ни о каком BSD su не может идти и речи. Правда, в какой-нибудь генте может быть и BSD su(?) [не проверял].