Исходное сообщение
"(offtopic) разные околобезопасные штуки" Отправлено Michael Shigorin, 09-Окт-07 12:22
>>> если бы там были действительно серьезные проблемы из-за общего /tmp, >>> в большинстве дистрибутивов уже давным давно бы реализовали >>> отдельные /tmp для каждого пользователя. >> Дело не только в том, что общий, а и в том, что known world writable. >$ ll / | grep tmp BTW ls -ld /tmp ;-) >если внутри /tmp создавать файлы/каталоги с правами 700 - в чем проблемы? В том, что они могут быть _уже_ созданы.  Недавно в одной из мониторилок почти случайно () наткнулся на забытый дебаг, который от рута писал в /tmp/чегототам.log и остался в if 1, а не if 0.  Чегототам забито гвоздями и не зависит даже от pid. >или я чего-то не понимаю? Не помню точное название, но существует несколько классов атак с применением известности общедоступности по чтению/записи /tmp и известности или возможности угадать/довести до race condition создание временных файлов/каталогов.  Соответственно и всякие fchmod() неспроста появились... >а то, что все временные файлы собраны в одном месте - так >это же наоборот, очень хорошо. Изрядно плохо.  См., например, https://bugzilla.altlinux.org/show_bug.cgi?id=8030 (в ALT это теперь регулируется, раньше дефолтом был TMPDIR=$HOME/tmp/). >удобно ведь, когда все логи лежат в /var/log /var/log/чтотоещё/ -- удобней, особенно при необходимости раздачи и контроля прав. >а все файлы пользователя в /home/$user. IMHO -- включая временные ;-) >если ты про 6.0 - то там пишут что suid они также не используют: Деталей не изучал, но с точки зрения пользователя-то -- эквивалент... >http://www.postfix.org/security.html >Introducing the concept was the biggest mistake made in UNIX history. >Set-uid (and its weaker cousin, set-gid) causes more trouble than it is >worth. Да, это одна из трёх основных проблем дизайна UNIX (suid, root, /tmp). >>> если действительно нужно обеспечить высокий уровень безопасности - пользуются SELinux. >> Зависит. >так ведь других нормальных вариантов просто нет. Есть, просто нормальность нормальности рознь.  RSBAC успешно применялся, в т.ч. по банковским и силовым структурам, ещё лет шесть тому. >PPS ты мой емейл от 22 числа получил? Да, но тут точно пошли в почту.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>>> если бы там были действительно серьезные проблемы из-за общего /tmp, >>>> в большинстве дистрибутивов уже давным давно бы реализовали >>>> отдельные /tmp для каждого пользователя. >>> Дело не только в том, что общий, а и в том, что known world writable. >>$ ll / | grep tmp > BTW ls -ld /tmp ;-) >>если внутри /tmp создавать файлы/каталоги с правами 700 - в чем проблемы? > В том, что они могут быть _уже_ созданы. Недавно в одной > из мониторилок почти случайно () наткнулся на забытый дебаг, который от > рута писал в /tmp/чегототам.log и остался в if 1, а не > if 0. Чегототам забито гвоздями и не зависит даже от > pid. >>или я чего-то не понимаю? > Не помню точное название, но существует несколько классов атак с применением известности > общедоступности по чтению/записи /tmp и известности или возможности угадать/довести до > race condition создание временных файлов/каталогов. Соответственно и всякие fchmod() > неспроста появились... >>а то, что все временные файлы собраны в одном месте - так >>это же наоборот, очень хорошо. > Изрядно плохо. См., например, https://bugzilla.altlinux.org/show_bug.cgi?id=8030 > (в ALT это теперь регулируется, раньше дефолтом был TMPDIR=$HOME/tmp/). >>удобно ведь, когда все логи лежат в /var/log > /var/log/чтотоещё/ -- удобней, особенно при необходимости раздачи и контроля прав. >>а все файлы пользователя в /home/$user. > IMHO -- включая временные ;-) >>если ты про 6.0 - то там пишут что suid они также не используют: > Деталей не изучал, но с точки зрения пользователя-то -- эквивалент... >>http://www.postfix.org/security.html >>Introducing the concept was the biggest mistake made in UNIX history. >>Set-uid (and its weaker cousin, set-gid) causes more trouble than it is >>worth. > Да, это одна из трёх основных проблем дизайна UNIX (suid, root, /tmp). >>>> если действительно нужно обеспечить высокий уровень безопасности - пользуются SELinux. >>> Зависит. >>так ведь других нормальных вариантов просто нет. > Есть, просто нормальность нормальности рознь. RSBAC успешно применялся, в т.ч. по > банковским и силовым структурам, ещё лет шесть тому. >>PPS ты мой емейл от 22 числа получил? > Да, но тут точно пошли в почту.
	Введите код, изображенный на картинке: