Список следящего ПО (безопасная установка Debian)

Виртуалки вообще не предназначены для приватности/анонимности в понимании параноиков.

Объясните, как безопасно пользоваться Тор-браузером, ведь отключение скриптов, по-вашему, сильно снизит анонимность. А со скриптами уровень безопасности таков, что ставит под сомнение анонимность. (Только про селинукс не надо писать). Получается что единственный способ достичь максимальной анонимности – это запустить Тор-браузер в виртуальной машине. Можно наверное ещё chroot попробовать, как более простой вариант.

Мелко плаваете параноите.

Chroot тоже не имеет отношения к безопасности. Майк Перри пишет, что мы все умрём от кибервойны ничего не спасёт, даже выполнение кода на разных машинах, Air Gap эксплойты уже заготовлены, похищение ключей разработчиков Tor'a и дистрибьютеров, компрометация всей его инфраструктуры (и затроянивание дистрибутивов Linux заодно) — вполне реальный сценарий, вопрос времени. Так что пока ждём разработки детерминированной компиляции и групп присмотра за сборками.

I don't believe it is possible to keep software signing keys secure any more, nor do I believe it is possible to keep even an offline build machine secure from malware injection any more, especially against the types of adversaries that Tor has to contend with.

Первым начнут укреплять Debian, на нём и обкатают сборку TBB.

Если дела и дальше будут идти так плохо, то разрешат отключать вообще всё:

In the meantime, we are investigating giving advanced users a way to enable text-mode only browsing and other usability-destructive tradeoffs via a security slider at startup:

https://trac.torproject.org/projects/tor/ticket/9387

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

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

И что мешает приложению воспользоваться уязвимостью в рутовом процессе? Или поднять себе привилегии, через проблему в одном из модулей ядра :)

Меня как UNIX'оида взращивали и обучали гентушники, которые мигрировали с BSD в 2003-ем, ставили генту с положенным крещением огнём ещё в 2004-ом и пользовались ей вплоть до 2011-го, если не вру. У них был несоизмеримый со мной опыт, и в настройке BSD мне немало помогали. Я не могу сейчас вам пересказать всё то, что я наслушался про генту последние лет за 7, тем более, что это говорили не эникеи, а те, кто в командной строке чувствовал себя вольготно, фиксил баги в сорсах, писал репорты и т.д. и пр. Основной мотив был в том, гента — хорошая система, продуманная, во всём устраивает, но чтобы она была в рабочем состоянии, чтобы ей пользоваться, а не постоянно красноглазить и фиксить баги, ждать ебилды, пиная мейнтейнеров... нужны нормальные мейнтейнеры, которые будут её держать в актуальном и конситентном состоянии. Иначе вы будете делать их работу за них (читай «красноглазить»). Народ постарел, от красноглазия устал и постепенно мигрировал на другие дистриубтивы. Проблема выбора дистрибутива была насущной темой философских споров втечение многих лет; всё, что можно было сказать, было сказано, по итогам чего был выработан консенсус «что угодно, но только не Gentoo». Я предпочёл доверять тем, кто имеет многолетний опыт работы с ней, а не повторять чужие ошибки на собственной шкуре.

Позже мне пришлось лишь единожды иметь дело с гентой, это была чужая система на каком-то хостинге, и из-за того, что пол-года её никто не обновлял, она была полностью outdated. Хорошо, мне гентушники помогли обновить её до нужной кондиции, чтобы установить один нужный мне пакет более новой версии. При этом пришлось снести и переустановить половину системы. Если бы хоть одно действие увенчалось фейлом, был бы кирдык. Это вам не BSD, где есть полная отвязка системы от портов, Gentoo — она состоит из портов, поэтому нездоровое обновление может легко угробить всю систему. Короче, рисковать так в продакшне мало кому захочется. Да, есть другие вроде как профессиональные дистрибутивы, но у них полтора пользователя и примерно такой же уровень поддержки, поэтому совсем экзотику я выбирать не стал принципиально, остановился на Debian, как меньшем зле из множества зол.


Ну да, я же вам об этом когда-то и сообщал. Думаю, просто Тео ломает имплементить поддержку паравиртуализации в ядро, и это надо чем-то оправдать. Если бы поломать гипервизор был бы столь элементарно, хостинги бы ломали как нефиг делать, а ведь гипервизор там — это единственное, что ограничивает пользователей (рут в своём доме и так у всех есть). Конечно, за словами Тео есть изрядная доля истины, но я всё же склонен считать, что гипервизор добавляет ещё один уровень безопасности, не ослабляя существующий. И я не веду речь о полностью скомпрометированных домах, консерватно полагая, что потенциальный зловред будет сидеть в доме под непривелегированным пользователем. Наконец, в любом случае, нормальная анонимность невозможна без виртуалок, сейчас это все понимают.


Нда, скучать не приходится. Атаки всегда становятся только сильнее. ©


Уже давно должны были позволить, а они только сидят-раздумывают, и при этом сами же признают, что это вопрос исключительно usability, т.е. политический.

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

Я заметил, что в Debian Wheezy постоянно, каждые несколько секунд, всплывает в top процессов rts5139-polling, раскручивая кулер. При любой операции с TBB это тоже происходит. Из поверхностного чтения гугла выяснил, что это какой-то баг в современных версиях Linux, из-за которого ядро постоянно опрашивает SD-кард-ридер, даже когда там нет карты (или и самого кард-ридера). Здесь советуют сделать rmmod rts5139 для решения проблемы. Стоит ли последовать этому совету? Могут ли быть какие-то следствия для безопасности? Т.е. они предлагают выгрузить из ядра соответствующий модуль.

Не наблюдаю такой проблемы. Модуль лежит, если посмотреть find /lib/modules -name "rts*", но по lsmod | grep lts он вообще не загружен. При наличии картридера. Так что можно выгружать, проверите только, работает ли картридер после этого.

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

Если кто-то может напишите подробную и понятную новичкам инструкцию.

unknown:
Модуль лежит, если посмотреть find /lib/modules -name "rts*", но по lsmod | grep lts он вообще не загружен.

С lts Вы не ошиблись?

Ошибся. s/lts/rts//g

В любом случае, модуль не загружен.

И что мешает приложению воспользоваться уязвимостью в рутовом процессе? Или поднять себе привилегии, через проблему в одном из модулей ядра

Известно что запускать процесс в песочнице имеет смысл только от непривилегированного пользователя. Поэтому речь только об этом случае. Если вы знаете лёгкий способ выхода из неё, поделитесь информацией. Вы считаете, как и unknown, что делать chroot для сетевого приложения бессмысленно?

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

Другой вопрос про delay/timeout. После ввода неправильного пароля он делает таймаут в несколько секунд, как его сократить? В man ничего не вижу на эту тему. Если пароль сильный, то от такой опции одно неудобство. Этот же вопрос есть и про консоль: ввёл неправильно — потом долго ждать, пока ввод пароля запросится снова. Неужли недостаточно долей секунды для задержки? Кто-то, наверно, думает, что пароль будут подбирать, сидя за клавиатурой руками, и для сверхслабых паролей эти таймауты от чего-то спасут. Стыд полный.

И третий вопрос про приглашение ввода авторизации в консоли. Кто-нибудь знает, как его поменять так, чтобы не писался тип системы и имя хоста?

Другой вопрос про delay/timeout. После ввода неправильного пароля он делает таймаут в несколько секунд, как его сократить? В man ничего не вижу на эту тему.

Он должен использовать глобальные параметры PAM, в том числе для таймаута; сделать таймаут меньше, чем задано в PAM, как я подозреваю, нельзя. Здесь есть некоторая информация, какие он использует конфиги.

И третий вопрос про приглашение ввода авторизации в консоли. Кто-нибудь знает, как его поменять так, чтобы не писался тип системы и имя хоста?

/etc/issue
man issue

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

При установке системы, когда ещё не заведено куча пользователей с паролями в /etc/login.defs можно поставить ENCRYPT_METHOD SHA512 вместо DES и подобрать увеличение параметра SHA_CRYPT_MAX_ROUNDS. Это не спасёт от сверхслабых паролей, но усложнит подбор при чтении и похищении таблицы shadow-паролей.