Простые меры безопасности (но эффективные)

[Bolverk]

Вот появилась идея обсудить меры безопасности, которые с одной стороны достаточно просты, с другой обладают неплохой эффективностью. Начну с параметров монтирования.
Хочу обратить ваше внимание на такие параметры монтирования, как nodev,noexec, nosuid. Как и все другие опции монтирования, их можно просто прописать в /etc/fstab "и забыть". Сразу замечу, что их применение возможно только в том случае, когда некоторые стандартные части базовой файловой системы (/usr,/var,/home и т. д.) вынесены на отдельные разделы. Почему - будет ясно дальше.
Итак, предположим что у нас все разбито по максимуму - /home, /var, /usr, /tmp, далее по вкусу, вынесены на отдельные разделы. Теперь посмотрим, что делают эти опции и в каких случаях их не стоит применять (почти всегда стоит). Для рутовой партиции они не нужны и могут быть опасны.
nodev - запрещает создавать на разделе файлы устройств. Точнее, такие файлы не будут восприниматься как файлы устройств. В обычном случае все файлы устройств расположены в /dev, который расположен на рутовом разделе. Создание файлов устройств в других местах нужно либо в нестандартных случаях (мне такие не известны), либо такая возможность может очень пригодится "хакеру". Если, например, вдруг в связи с какой-нибудь ошибкой враг получит возможность создать файл устройства (например, соответcтвующий /dev/hda), то что может быть легче записывания в него (= в жесткий диск) всякого мусора, что приведет к неработоспособности системы. Возможны и более сложные варианты. Вывод - все разделы, кроме рутового, монтируем с nodev.
noexec - запрещает исполнять исполняемые файлы на разделе. Звучит может и дико, но это так. В этом случае файлы с аттрибутом "исполняемый" не будут исполняться. Выгода - еще один уровень защиты от rootkit. Обычно исполняемые файлы располагаются в /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin и в домашних каталогах пользователей. То есть на рутовой партиции и в глубинах /usr, /home (и /usr/local). Все остальные разделы можно, подумав, монтировать с этой опцией. А подумать необходимо потому, что могут быть ситуации, когда наличие исполняемых файлов необходимо в других каталогах - chroot окружение, еще что. В каталог /opt часто ставятся "целиком" большие програмные пакеты, включая исполняемые файлы. Пользователи наверно тоже захотят иметь возможность запускать собственные скрипты и самосборные программы, но если вы злобный админ, то и на /home можно запретить исполнение. Так что пробуйте, но у меня все разделы кроме /, /usr, /home смонтированы с этой опцией, и ошибок не замечено.
nosuid - запрещает исполняемые файлы с так называемыми sticky iud bit, который значит, что файл будет исполняться с правами владельца независимо от того, кто его запустил. Обычно это используется для "разрешения" пользователям выполнения неких действий, требующих повышенных прав. Такие программы представляют потенциальную опастность и в обычной ситуации должны существовать только на / и /usr (опять таки, может быть /opt). Вывод - все остальное монтируем с nosuid.
Эти меры, как было сказано, с одной стороны достаточно просты, с другой дают некую дополнительную защиту от врага. Конечно, при неверном применение они могут помешать нормальной работе системы, но основные моменты я вроде оговорил. Обсуждение и поправки приветствуются.
В заключение добавлю о возможности монтирования разделов в режиме чтения (ro). Я такое успешно применяю с /usr, где крайне редко необходима возможность записи, для чего раздел "на лету" перемонтируется в режим записи, а потом опять в только чтение:
mount -o rw,remount /usr
mount -o ro,remount /usr
Дополнительная информация - man mount
Источник - man mount (фактический), Linux Security HOWTO или нечто с похожим названием (идейный).

[Jinn]

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

Пользователи наверно тоже захотят иметь возможность запускать собственные скрипты и самосборные программы, но если вы злобный админ, то и на /home можно запретить исполнение.

Ну конечно захотят! А почему бы им не иметь собственные скрипты, или если они пишут программы? И с точки зрения безопасности - всё нормально, порушат только себя и ничего больше. Поэтому не понятно, зачем им это запрещать.

В заключение добавлю о возможности монтирования разделов в режиме чтения (ro). Я такое успешно применяю с /usr, где крайне редко необходима возможность записи, для чего раздел "на лету" перемонтируется в режим записи, а потом опять в только чтение:

Для безопасности - это действительно хорошо. А если часто приходиться что-то самому собирать? Тогда такая мера просто теряет смысл, т.к. раздел всё равно всё время будет открыт для записи. Но можно для такого случая предложить альтернативу. А именно, создать отдельный раздел /usr/src под предполагаемые нужды. А посколку там всё равно ничего кроме исходников и пакетов нет, то и монтируй его себе на здоровье как угодно, а на сам /usr пиши уже готовое.
Есть еще такая мыстль - а не очищать ли /tmp при загрузке? Ведь и там встречается многое, что не желательно передавать в чужие руки.

[madskull]

Полагаю, эту статью нужно было сразу в ФАК.
У меня на серверах примерно так и организовано.

А /tmp во всех (мне известных) дистрах и так очищается.
А по поводу сборки/разборки... Какая, нафиг, сборка на сервере? На сервере вообще не должно быть девелоперских пакетов. (правда, я за свою недолгую карьеру админа не имел дела с серверами с "публичным" доступом для пользователей, отсюда и такая точка зрения)

[Bolverk]

Jinn
Так я и написал: "Еcли вы злобный админ"
Можно и отдельный раздел для /usr/src, да и для /usr/local тоже можно отдельный раздел.
А /usr/src у меня симлинк на /var/src, и вообще большинство программ собирается в ~/src (или ~/tmp/RPM/BUILD ). Насчет /usr/tmp не помню, то ли нету, то ли симлинк.
А к /tmp у меня прикручена tmpfs, которая вообще виртуальная и сидит в памяти, поэтому после перезагрузки ее содержимое пропадает. Кстати занято в /tmp обычно несколько килобайт .

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

[Jinn]

А /tmp во всех (мне известных) дистрах и так очищается

Можно ли сделать вывод, что Mandrake тебе неизвестен? А там это нужно установить отдельно. Причём накапливается иногда очень нехило - десятки мег.

Какая, нафиг, сборка на сервере?

В статье я вообще такого слова "сервер" не заметил, а потому и решил что речь шла об общем случае.

Так я и написал: "Еcли вы злобный админ"

Ну тут нужно быть не просто "злобным", чтобы запрещать то, что никому не угрожает! Да и статья-то о безопасности или админских предпочтениях?

Можно и отдельный раздел для /usr/src, да и для /usr/local тоже можно отдельный раздел.

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

Кстати занято в /tmp обычно несколько килобайт

Нет, серьёзно? Это в каком же дистрибе такое?

[Bolverk]

Какая, нафиг, сборка на сервере?

В статье я вообще такого слова "сервер" не заметил, а потому и решил что речь шла об общем случае.

↑

Да, по крайней мере я имел в виду первоначально общий случай или даже скорее домашнюю машину.

Ну тут нужно быть не просто "злобным", чтобы запрещать то, что никому не угрожает! Да и статья-то о безопасности или админских предпочтениях?

↑

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

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

↑

Нет, это не ирония. Про злобного админа была ирония, а это нет. У меня был раздел /usr/local, пока я не осознал его ненужность для меня. А по ситуации могут быть разделы и /var/www, и /var/cache/squid и все что придумаешь.

Кстати занято в /tmp обычно несколько килобайт

Нет, серьёзно? Это в каком же дистрибе такое?

↑

См. подпись. В основном это открытые сокеты. Иногда туда кладутся временные файлы, с которыми ведется интенсивная работа. Все, что хоть чуть-чуть ценно (должно пережить штатную перезагрузку), идет в /var/tmp. Кажется это даже какой-то стандарт.

[madskull]

А /tmp во всех (мне известных) дистрах и так очищается

Можно ли сделать вывод, что Mandrake тебе неизвестен?

Можно!

Какая, нафиг, сборка на сервере?

В статье я вообще такого слова "сервер" не заметил, а потому и решил что речь шла об общем случае.

Так я же сделал там поправочку:
(правда, я за свою недолгую карьеру админа не имел дела с серверами с "публичным" доступом для пользователей, отсюда и такая точка зрения)

[alv]

Стратегия разбиения диска (монтирования etc.) с точки зрения безопасности для меня представляет интерес чисто теоретический. А вот с точки зрения удобства десктопного использования и быстродействия - практический. И много по сему поводу размышляю и экспериментирую.

1. Обсудим?

2. Здесь или в отдельном трейде?

[t.t]

1. Обсудим?

2. Здесь или в отдельном трейде?

↑

1. На первый вопрос ты, судя по всему сам ответил вторым
2. Я думаю, лучше отдельно.

[alv]

1. Обсудим?

2. Здесь или в отдельном трейде?

↑

1. На первый вопрос ты, судя по всему сам ответил вторым
2. Я думаю, лучше отдельно.

↑

Сказано - сделано: Стратегия управления файловыми системами