Spiegazione di nodev e nosuid in fstab

Vedo queste due opzioni costantemente suggerite sul web quando qualcuno descrive come montare un tmpfs o ramfs. Spesso anche con Noexec ma sono particolarmente interessato a nodev e nosuid. Fondamentalmente odio solo ripetere ciecamente ciò che qualcuno ha suggerito, senza una vera comprensione. E poiché vedo solo le istruzioni di copia / incolla in rete in merito, chiedo qui.

Questo è dalla documentazione:
nodev - Non interpretare i dispositivi speciali a blocchi sul filesystem.
nosuid : blocca l'operazione dei bit suid e sgid.

Ma vorrei una spiegazione pratica di cosa potrebbe accadere se lascio fuori quei due. Diciamo che ho configurato tmpfs o ramfs (senza queste due opzioni menzionate) che è accessibile (leggi + scrivi) da un utente specifico (non root) sul sistema. Cosa può fare quell'utente per danneggiare il sistema? Escludendo il caso di consumare tutta la memoria di sistema disponibile in caso di ramfs

linux security fstab

— Ivan Kovacevic
fonte

Questa è una buona risposta alla tua domanda

— Vista ellittica

Non è necessario seguire questo alla cieca come una regola difficile. Ma il ragionamento per situazioni più incentrate sulla sicurezza è il seguente.

L'opzione nodev mount specifica che il filesystem non può contenere dispositivi speciali: questa è una precauzione di sicurezza. Non si desidera che un filesystem accessibile in tutto il mondo come questo abbia il potenziale per la creazione di dispositivi a caratteri o l'accesso a dispositivi hardware casuali.
L'opzione nosuid mount specifica che il filesystem non può contenere file userid impostati. Prevenire i binari setuid su un filesystem scrivibile in tutto il mondo ha senso perché c'è il rischio di escalation di root o di altre terribili cose lì.

Per quello che vale, non uso spesso questi parametri ... solo su sistemi pubblici dove ci sono altre considerazioni sulla conformità.

— ewwhite
fonte

In realtà ho un sistema pubblico perché il software è in esecuzione con quell'account che è esposto alla rete. Quindi mi chiedo quali scenari ipotetici qui. Che cosa succede se qualcuno ottiene l'accesso alla shell attraverso qualche vulnerabilità. Naturalmente ci sono altre cose che potrebbe fare per intensificare i diritti, ma preferirei minimizzarli. Quindi mi chiedo ad esempio per il suid se l'utente non fosse ancora in grado di cambiare quel flag indipendentemente dal fatto che il filesystem lo permetta o meno. L'opzione nosuid impedisce quindi solo software accidentale mal configurato (da un root)? O un utente può sfruttarlo da solo?

— Ivan Kovacevic,

@IvanKovacevic Non è necessario utilizzare le opzioni di montaggio del filesystem consigliate. Sono lì per ridurre il vettore di attacco. L'esame di scenari ipotetici potrebbe tuttavia andare oltre lo scopo di questa domanda.

— ewwhite,

@ewwhite: riguardo nosuidal bit setuid non viene ignorato? (invece di The nosuid mount option specifies that the filesystem cannot contain set userid files)

— user2284570