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

Не знаю, нет определённой статистики. Источники вроде разные, но на 100% не поручусь.


По-моему, почти все проигрыватели под Linux — mplayer и его производные. Ну, vlc ещё относительно популярен.

Firefox, который был взят для сравнения — кроссплатформенный. А эксплойты в нём использовались в основном под винду. Mplayer, вроде бы тоже кроссплатформенный, но рассчитывать, что массовый пользователь будет открывать файл именно им, не следует. Эксплойты в нём могут быть использованы скорее только как узко целенаправленные. И возможно, массово распространяемые специально сформированные медиафайлы рассчитаны на уязвимости в других плэйерах и операционках.

unknown, как Вы решаете для себя проблему с systemd в Debian?

Сидит, поди, на том релизе, в котором systemd ещё не было.

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

В текущих стабильных релизах systemd пока ещё по умолчанию не ставится.

Приучайтесь ставить все дистры в режиме "expert-install" в минимальной инсталляции без иксов, с доустановкой всех нужных вам пакетов из системы далее вручную, чтобы не было неожиданных сюрпризов по поводу того, что что-то выбрали за вас по умолчанию. И перед выходом каждого релиза читайте мануал, где подробно описано, что внедрили нового и как ставить. Желательно читайте на английском, а не в переводе. Хотя переводы там вроде как нормальные.

Браузер iceweasel грохнулся от чего-то в кору (были плагины и расширения, а также флэш). После коры обнаружилась директория /tmp/plugtmp (вроде бы в норме у меня она там не создаётся, но не поручусь за это), в которой был файл plugin-crossdomain.xml с содержимымПогуглил, ничего такого не нашёл, хотя пишут, что на винде в plugtmp любят всякую вирусню засовывать. Ещё на одной странице был намёк, что это может быть вызвано автоматическим обновлением флэша. Кто-нибудь знаком с внутренностями браузера, чтоб прокомментировать?

Вопрос не по теме, но и создавать новую наверно не стоит. Кто знает что за релиз: Lilblue Linux (http://opensource.dyc.edu/node/350)

Там же дана ссылка + в самом тексте есть объяснения. Очередной дистр на основе генты. Дистрибутив дистрибутива Gentoo Linux.

Тема vim'а, пост о п-сах.

Суть: файл ~/.vim/.netrwhist, в который утекают данные. Про emacs говорят, что это хорошая ОС, в которой нет редактора. Видимо, vim решил восполнить этот пробел, добавив к редактору функции ОС. Зачем это всё тащить в редактор? Вопрос риторический. Интересное:

There's no built-in way to prevent .netrwhist generation at the current time. However, you could delete the file immediately after it was generated, I suppose: (untested) with the following Voodoo cult:
au VimLeave * if filereadable("[path here]/.netrwhist")|call delete("[path here]/.netrwhist")|endif

netrw_dirhistmax indicates the maximum number of modified directories it stores in the history file

set netrw_dirhistmax=0 в ~/.vimrc закроет утечку?

По ссылкам [1], [2], [3] обсуждается правка сорсов и особо извращённый культ вуду с переменной runtimepath. Что куда прописать, чтобы поменять местоположение директории ~/.vim, так и не понял. Хуже то, что я не совсем понимаю, при каких условиях она создаётся и туда что-то пишется (я не хожу на удалённые сервера, максимум — выполняю скрипты на других файловых системах, но не удаётся создать тестовый пример).

На ум приходят ещё 4 хака:

1. В конфиге шелла перед стартом шелла проверять, есть ли нужная директория в /tmp, и, если нет, то создавать её и директорию vim в ней, а домашюю ~/.vim сделать симлинком на неё.
2. Создать ~/.vim и снять у неё права на запись, в надежде, что vim не настолько наглый, чтобы писать в какое-то третье место.
3. Сделать алиас на vim с изменённым $HOME. В этом случае оно почему-то конфликтует с опцией для viminfo:

   $ HOME=/tmp vim -u /home/USERNAME/.vimrc /path/to/FILE
   Error detected while processing /home/USERNAME/.vimrc:
   line   XX:
   E528: Must specify a ' value: viminfo+=n/tmp/.viminfo-$USER
   Press ENTER or type command to continue

4. Создавать динамически директорию в /tmp как в п.1, а опцию с viminfo убрать из конфига вообще, т.к. она должна будет сразу создаваться уже там, по новому адресу. Не тестировал.

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

NetRW provides g:netrw_dirhistmax as a way to prevent creating the .netrwhist and .netrwbook files. However, even when this variable is <=0 NetRW will create the home directory to store these files. The attached patch changes this to only create the home directory if the files are also going to be created.

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

Hiding processes from other users. В новых ядрах можно включить невидимость процессов для других пользователей: процесс будет виден только пользователю, который его запустил и руту. В новых версиях Debian будет сделано по умолчанию.

Раньше что-то подобное было только в SELinux и GRSecurity.

Да, в ядре Linux наметился потрясающий успех. В ядре FreeBSD эта «фича» была ещё 10 лет назад — достаточно было в конфиге ядра одну строчку раскомментировать. И никакие сторонние патчи к ядру были не нужны. В OpenBSD одно время были сторонние любительские патчи для реализации этой фичи, но поддерживать их было некому, поэтому по факту там этого штатно вроде как нет до сих пор. В NetBSD не было даже таких сторонних патчей. И вообще, ОС — это точка доверия между пользователями системы, а не точка конфронтации между ними — философия такая. Кому не нравится, должны использовать виртуалки.

А здесь ядро перекомпилять не надо. Достаточно изменить параметр в /proc на лету из под рута. Иди внести параметр монтирования /proc в /etc/fstab.


Слишком сильное утверждение, легко сводимое к абсурду. Так можно сказать, что и права не нужны и ACL. Пусть тогда всем будут прописаны беспарольные права рута через sudo. В том числе для серверов, торчащих наружу в сеть. А кому не нравится — пусть используют виртуалки.

Но ведь разработчики архитектуры UNIX именно так и думали, иначе вы ничем не объясните те факты, что

1. Список процессов каждого юзера виден всем.
2. Права на создаваемые файлы и директории по умолчанию таковы, что дают доступ на чтение вообще всем.
3. Каждый пользователь имеет широкие права доступа к системным ресурсам: просмотру сетевых настроек, логов ядра, списку пользователей и групп, логам последних логинов пользователей и длительности их сессий... список можно продолжать бесконечно.
4. По умолчанию нет никаких квот на системные ресурсы: память, процессор, дисковое пространство, поэтому повесить намертво систему — нефиг делать. Идут года, но ничего не меняется: каждое поколение вновь открывает для себя эти форк-бомбы. И даже самые красноглазые, которые долго игрались с ulimit, прекрасно вырубаются специально написанными эффективными форк-бомбами.

Эти пункты логично объясняются тем, что «все работают над одним общим делом», и «никто не будет друг другу намеренно вредить», «вредителю просто отрежут доступ к серверу». Сервера и истино многопользовательские системы, где «никому доверять нельзя» появились намного позже, чем создавался UNIX, и они до сих пор страдают от изъянов исходной архитектуры безопасности. Впрочем, о чём вообще может идти речь, если изначально там был telnet, а не ssh, т.е. все пароли передавались открытым текстом? Попытка прикрутить безопасность задним числом приводит к тому, что имеем.


Общий принцип на серверах — «доступ кому попало не давать». По сути на сервере остаётся только административный персонал, у которого и так рут есть. По этой же причине исходную идеологию «давайте всем сервисам, требующим аккаунты, будем создавать аккаунты системных пользователей» стали заменять на другую, где системные юзеры создаются сторонним приложением, и только оно управляет доступом. Ещё давно это было сделано для дырявой SAMBA'ы, а сейчас, наверное, вообще почти для всего так.

На десктопах мы видим тот же результат, но по другим причинам: юзер сам себе типа не враг, поэтому по умолчанию sudo вообще пароля на рута не требует. Обычный ПК — не «система для безопасной обработки данных», «нормальному юзеру скрывать нечего», поэтому общий крен сейчас как раз в сторону демонтирования даже тех систем защиты, которые в исходном UNIX'е были.


Похоже, топик начал оправдывать ваши прогнозы.