94 votes

Explication de nodev et nosuid dans fstab

Je vois ces deux options constamment suggérées sur le web lorsque quelqu'un décrit comment monter un tmpfs ou un ramfs. Souvent aussi avec noexec mais je suis spécifiquement intéressé par nodev et nosuid. Je déteste essentiellement le fait de répéter aveuglément ce que quelqu'un a suggéré, sans vraiment comprendre. Et comme je ne vois que des instructions copier/coller sur le net à ce sujet, je demande ici.

Ceci est tiré de la documentation :
nodev - Ne pas interpréter le blocage des périphériques spéciaux sur le système de fichiers.
nosuid - Bloque le fonctionnement des bits suid, et sgid.

Mais j'aimerais avoir une explication pratique de ce qui pourrait se passer si je laisse ces deux-là de côté. Disons que j'ai configuré tmpfs ou ramfs (sans ces deux options) qui est accessible (lecture+écriture) par un utilisateur spécifique (non-root) sur le système. Que peut faire cet utilisateur pour endommager le système ? À l'exception de la consommation de toute la mémoire système disponible dans le cas de ramfs.

2 votes

C'est une bonne réponse à votre question : unix.stackexchange.com/questions/188601/

77voto

ewwhite Points 193555

Vous ne devez pas suivre aveuglément cette règle absolue. Mais le raisonnement pour les situations plus axées sur la sécurité est le suivant.

  • L'option de montage nodev spécifie que le système de fichiers ne peut pas contenir de périphériques spéciaux : Il s'agit d'une précaution de sécurité. Vous ne voulez pas qu'un système de fichiers accessible au monde entier par un utilisateur comme celui-ci ait le potentiel pour la création de dispositifs de caractères ou l'accès au matériel d'un dispositif aléatoire.

  • L'option de montage nosuid spécifie que le système de fichiers ne peut pas contenir de fichiers set userid. Empêcher les binaires setuid sur un système de fichiers inscriptible dans le monde entier est logique car il y a un risque d'escalade de la racine ou d'autres horreurs.

Pour ce que ça vaut, je n'utilise pas souvent ces paramètres... seulement sur les systèmes publics où il y a d'autres considérations de conformité.

1 votes

J'ai en fait un système public parce que le logiciel fonctionne sous ce compte qui est exposé au réseau. Je m'interroge donc sur les scénarios possibles. Et si quelqu'un obtenait un accès à Shell par le biais d'une vulnérabilité. Bien sûr, il y a d'autres choses qu'il pourrait faire pour escalader les droits, mais j'aimerais plutôt les minimiser. Je me demande donc si, par exemple, pour suid, l'utilisateur ne serait pas toujours en mesure de modifier ce drapeau, que le système de fichiers l'autorise ou non. Est-ce que l'option nosuid n'empêche que les logiciels accidentellement mal configurés (par un root) ? Ou un utilisateur peut-il l'exploiter seul ?

1 votes

@IvanKovacevic Vous n'êtes pas obligé d'utiliser les options de montage de système de fichiers recommandées. Elles sont là pour réduire le vecteur d'attaque. L'examen des scénarios de simulation peut dépasser le cadre de cette question, cependant.

3 votes

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

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X