Объяснение nodev и nosuid в fstab

Я вижу эти два варианта, постоянно предлагаемые в Интернете, когда кто-то описывает, как смонтировать tmpfs или ramfs. Часто также с noexec, но меня особенно интересуют nodev и nosuid. Я в основном ненавижу просто слепо повторять то, что кто-то предлагал, без реального понимания. И так как я вижу только инструкции по копированию / вставке в сети, я спрашиваю здесь.

Это из документации:
nodev - Не интерпретировать блокирование специальных устройств в файловой системе.
nosuid - блокирует работу битов suid и sgid.

Но я хотел бы получить практическое объяснение того, что может произойти, если я оставлю эти два. Допустим, я настроил tmpfs или ramfs (без этих двух упомянутых опций), которые доступны (чтение + запись) определенному (не root) пользователю в системе. Что может сделать этот пользователь, чтобы нанести вред системе? Исключая случай использования всей доступной системной памяти в случае ramfs

linux security fstab

— Иван Ковачевич
источник

Это хороший ответ на ваш вопрос: unix.stackexchange.com/questions/188601/…

— эллиптический вид

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

Параметр mountv nodev указывает, что файловая система не может содержать специальные устройства. Это мера безопасности. Вы не хотите, чтобы доступная для пользователя файловая система, подобная этой, имела потенциал для создания символьных устройств или доступа к аппаратному обеспечению случайных устройств.
Параметр монтирования nosuid указывает, что файловая система не может содержать файлы заданных идентификаторов пользователей. Предотвращение двоичных файлов setuid в доступной для записи файловой системе имеет смысл, потому что есть риск эскалации корня или другой ужасной ситуации.

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

— ewwhite
источник

У меня фактически есть общедоступная система, потому что программное обеспечение работает под той учетной записью, которая доступна для сети. Так что я задаюсь вопросом о сценариях "что, если" здесь. Что делать, если кто-то получает доступ к оболочке через какую-то уязвимость. Конечно, есть и другие вещи, которые он мог бы сделать для расширения прав, но я бы предпочел свести их к минимуму. Поэтому мне интересно, например, для suid, если бы пользователь все еще не мог изменить этот флаг, независимо от того, позволяет файловая система это или нет. Является ли опция nosuid только предотвращением случайного плохо настроенного программного обеспечения (от рута)? Или пользователь может использовать его в одиночку?

— Иван Ковачевич

@IvanKovacevic Вам не нужно использовать рекомендуемые параметры монтирования файловой системы. Они там, чтобы уменьшить вектор атаки. Однако изучение сценариев «что, если» может оказаться за рамками этого вопроса.

— ewwhite

@ewwhite: в отношении nosuidбита setuid игнорируется? (вместо The nosuid mount option specifies that the filesystem cannot contain set userid files)

— user2284570