Explication de nodev et nosuid dans fstab

Je vois ces deux options constamment suggérées sur le Web lorsque quelqu'un explique comment monter un tmpfs ou un ramfs. Souvent aussi avec noexec, mais je suis particulièrement intéressé par Nodev et Nosuid. Je déteste fondamentalement juste répéter aveuglément ce que quelqu'un a suggéré, sans réelle compréhension. Et comme je ne vois que des instructions copier / coller sur le net à ce sujet, je demande ici.

Ceci provient de la documentation:
nodev - N'interprète pas les périphériques spéciaux en bloc sur le système de fichiers.
nosuid - Bloque le fonctionnement des bits suid et sgid.

Mais j'aimerais une explication pratique de ce qui pourrait arriver si je laissais ces deux personnes de côté. Supposons que j'ai configuré tmpfs ou ramfs (sans ces deux options mentionnées) accessible (en lecture + en écriture) à un utilisateur spécifique (non root) du système. Que peut faire cet utilisateur pour nuire au système? Hors cas de consommation de toute la mémoire système disponible en cas de ramfs

linux security fstab

— Ivan Kovacevic
source

Ceci est une bonne réponse à votre question Q: unix.stackexchange.com/questions/188601/…

— Vue elliptique

Vous n'êtes pas obligé de suivre aveuglément cette règle. Mais le raisonnement pour des situations plus centrées sur la sécurité est le suivant.

L'option de montage nodev indique que le système de fichiers ne peut pas contenir de périphériques spéciaux: Il s'agit d'une mesure de sécurité. Vous ne voulez pas qu'un système de fichiers tel que celui-ci, accessible au monde entier, permette la création de périphériques de caractères ou l'accès à du matériel de périphérique aléatoire.
L'option nosuid mount indique que le système de fichiers ne peut pas contenir les fichiers ID utilisateur définis. Empêcher les fichiers binaires setuid sur un système de fichiers inscriptible dans le monde a du sens car il existe un risque d'escalade de la racine ou d'autre horreur.

Pour ce que cela vaut, je n'utilise pas souvent ces paramètres ... uniquement sur les systèmes destinés au public, pour lesquels il existe d'autres considérations de conformité.

— ewwhite
source

En fait, j'ai un système destiné au public parce que les logiciels exécutés sous ce compte sont exposés au réseau. Je me demande donc quels sont les scénarios possibles. Et si quelqu'un obtenait un accès shell à travers une vulnérabilité? Bien sûr, il pourrait faire autre chose pour faire respecter les droits, mais je préférerais les minimiser. Je me demande donc, par exemple, pour suid, l'utilisateur ne serait-il toujours pas en mesure de modifier cet indicateur, que le système de fichiers le permette ou non. L'option nosuid empêche-t-elle uniquement les logiciels mal configurés par inadvertance (par une racine)? Ou un utilisateur peut-il l'exploiter seul?

— Ivan Kovacevic

@IvanKovacevic Il n'est pas nécessaire d'utiliser les options de montage recommandées du système de fichiers. Ils sont là pour réduire le vecteur d'attaque. L'examen de scénarios hypothétiques pourrait toutefois sortir du cadre de cette question.

— ewwhite

@ewwhite: nosuidle bit setuid n'est-il pas ignoré? (au lieu de The nosuid mount option specifies that the filesystem cannot contain set userid files)

— utilisateur2284570 le