>>> Не помню точное название, но существует несколько классов атак с применением
>>> известности общедоступности по чтению/записи /tmp и известности или возможности
>>> угадать/довести до race condition создание временных файлов/каталогов.
>> это атаки на ошибки в программах.
> Эти ошибки порождены схожими [неверными] предположениями о свойствах /tmp. после создания файла/каталога всегда можно проверить все ли с ним нормально -
правильно ли выставлены права доступа, тот ли владелец и не симлинк ли это.
например, пользователи ведь и вызовы malloc могут не проверять на успешность,
что ж тогда делать - встроить в ядро сборщик мусора или вообще запретить указатели?
>> я при каждом старте системы делаю rm -rfd /tmp/*
> Небезопасно
очень интересно, чем это может быть небезопасно?
если даже там будет лежать хардлинк на /etc/shadow - unlink() просто удалит "левое" имя.
если там будут лежать какие-то симлинки - rm будет удалять сам симлинк, а не target файл.
`rm -rfd /tmp/*` выполняется одним из первых инит-скриптов, с именем S00cleantmp
> в ALT на то есть отдельный stmpclean (s == secure, см.
> http://git.altlinux.org/people/ldv/packages/stmpclean.git).
насколько я понимаю, он расчитан на то, чтобы чистить /tmp на работающей машине.
т.е. чтобы админ мог периодически из cron запускать stmpclean вместо вот этого:
find /tmp -type f -atime +3 -ctime +3 ! -name '.X*-lock' -exec rm -f -- {} \;
find -d /tmp ! -name . -type d -mtime +1 -exec rmdir -- {} \; >/dev/null 2>&1
>>> См., например, https://bugzilla.altlinux.org/show_bug.cgi?id=8030
> агрегирование приватных (раздельных!) TMPDIR в одном месте (/tmp/.private/).
не понятно зачем в /tmp/.private/$USER вместо /tmp/$USER ?
в pam_mktemp ведь есть защита от различных race conditions.
>>>> а все файлы пользователя в /home/$user.
>>> IMHO -- включая временные ;-)
>>и чем это лучше варианта /tmp/$user ?
> Много мусора в /tmp, но это или вкусовое,
> или когда пользователей в ящике -- сотнями и больше.
каталог /tmp для мусора ведь и предназначен. и лучше он пусть будет там,
чем ровным слоем размазанный по всему разделу /home. тем более, что /tmp
может быть локальным разделом, а /home монтироваться по nfs из сервера.
особенно, когда tmp со временем переедет из обычной файловой системы на tmpfs,
что иметь одну файловую систему tmpfs, что несколько сотен - есть разница ведь.
>>> это одна из трёх основных проблем дизайна UNIX (suid, root, /tmp).
>>"критикуя - предлагай". если ты говоришь, что это плохо - предложи лучший вариант.
>Это был комментарий к тезису о "проблеме UNIX" -- что сродственных там больше.
> Предлагать -- не в моей компетенции.
насколько я понимаю большинство проблем /tmp решаемы с помощью pam_mktemp,
исключение - кривые программы, которые не смотрят на переменные окружения,
и всегда используют /tmp как каталог для временных файлов.
проблему с такими кривыми программами решает модуль pam_namespace (присутствует в Fedora),
The pam_namespace PAM module sets up a private namespace for a session with polyinstantiated directories.
A polyinstantiated directory provides a different instance of itself based on user name,
or when using SELinux, user name, security context or both.
и разумеется, защита каталога /tmp с помощью SELinux в RHEL и Fedora также присутсвует.
проблема с /tmp если решена не полностью, то на 80%-90%.
проблема с неограниченным root очень хорошо решается с помощью SELinux.
программа будучи запущена с uid 0 будет иметь минимально необходимый
для работы уровень привилегий. проблема решена почти на 100%.
suid - изменить это не так просто. хотя SELinux и тут
очень сильно минимизирует возможный ущерб при взломе.
PS учитывая, что UNIX уже более 30 лет (почти 40) - эта ОС получилась довольно удачной.
следующая версия, Plan9 имеет более правильный дизайн, но гораздо меньший успех. почему?
PPS кстати, я понял, почему мне не нравится термин "post-UNIX" применительно к Linux.
это очень сильно напоминает времена unix wars, ничем хорошим это тогда не закончилось.
