Explicación de nodev y nosuid en fstab

Veo esas dos opciones constantemente sugeridas en la web cuando alguien describe cómo montar un tmpfs o ramfs. A menudo también con noexec pero estoy específicamente interesado en nodev y nosuid. Básicamente odio repetir ciegamente lo que alguien sugirió, sin una comprensión real. Y como solo veo instrucciones de copiar / pegar en la red con respecto a esto, pregunto aquí.

Esto es de la documentación:
nodev : no interprete el bloqueo de dispositivos especiales en el sistema de archivos.
nosuid - Bloquea la operación de suid y sgid bits.

Pero me gustaría una explicación práctica de lo que podría pasar si dejo a esos dos fuera. Digamos que configuré tmpfs o ramfs (sin estas dos opciones mencionadas) que es accesible (lectura + escritura) por un usuario específico (no root) en el sistema. ¿Qué puede hacer ese usuario para dañar el sistema? Excluyendo el caso de consumir toda la memoria del sistema disponible en caso de ramfs

linux security fstab

— Ivan Kovacevic
fuente

Esta es una buena respuesta a su Q: unix.stackexchange.com/questions/188601/…

— Vista elíptica

No tiene que seguir esto a ciegas como una regla difícil. Pero el razonamiento para situaciones más centradas en la seguridad es el siguiente.

La opción de montaje de nodev especifica que el sistema de archivos no puede contener dispositivos especiales: esta es una precaución de seguridad. No desea que un sistema de archivos accesible para el mundo como este tenga el potencial para la creación de dispositivos de caracteres o acceso a hardware de dispositivo aleatorio.
La opción de montaje nosuid especifica que el sistema de archivos no puede contener archivos de ID de usuario establecidos. La prevención de archivos binarios setuid en un sistema de archivos de escritura mundial tiene sentido porque existe el riesgo de una escalada de raíz u otro problema allí.

Por lo que vale, no uso estos parámetros a menudo ... solo en sistemas públicos que tienen otras consideraciones de cumplimiento.

— ewwhite
fuente

De hecho, tengo un sistema público porque el software se ejecuta bajo esa cuenta que está expuesta a la red. Entonces me pregunto acerca de los escenarios hipotéticos aquí. ¿Qué pasa si alguien obtiene acceso de shell a través de alguna vulnerabilidad? Por supuesto, hay otras cosas que podría hacer para aumentar los derechos, pero preferiría minimizarlos. Entonces, me pregunto, por ejemplo, para suid, ¿el usuario aún no podría cambiar esa bandera sin importar si el sistema de archivos lo permite o no? ¿La opción nosuid solo previene un software accidental mal configurado (por una raíz)? ¿O puede un usuario explotarlo solo?

— Ivan Kovacevic

@IvanKovacevic No tiene que usar las opciones de montaje recomendadas del sistema de archivos. Están allí para reducir el vector de ataque. Sin embargo, examinar escenarios hipotéticos puede estar más allá del alcance de esta pregunta.

— ewwhite

@ewwhite: preocupante, nosuid¿no se ignora el bit setuid? (en lugar de The nosuid mount option specifies that the filesystem cannot contain set userid files)

— usuario2284570