Chmod / 777 erroneamente impostato. Problemi?

Stavo provando a correre chmod -R 777 ./ma ho finito per scrivere chmod -R 777 /e impostare 777su tutta la mia macchina. Cosa può andare storto? Come posso ripararlo?

I problemi? Sì, un sacco. Può essere riparato? Sicuro. Più veloce della reinstallazione? Probabilmente no.

La mia raccomandazione è di reinstallare. Conservare un backup del sistema esistente e ripristinare l'elenco dei pacchetti e il contenuto dei file in /etce /var. Per /usr/local, probabilmente è possibile ripristinare manualmente le autorizzazioni. Per /homee /srv, dovrai ripristinare le autorizzazioni dai backup.

Se si tratta di un sistema con più utenti locali, notare che rendere alcuni file leggibili in tutto il mondo ha rivelato alcune cose che avrebbero dovuto rimanere riservate.

• L'elenco delle password è ora compromesso: gli utenti locali hanno avuto accesso all'elenco delle password con hash e potrebbero provare a forzarle. Informa i tuoi utenti di questo.
• Tutti i dati degli utenti privati ​​(chiavi ssh, password archiviate, e-mail, qualunque altra cosa gli utenti possano considerare confidenziali) sono stati esposti a tutti gli utenti locali. Informa i tuoi utenti di questo.

Se vuoi davvero provare a riparare (più di un esercizio di apprendimento che una pratica via di recupero), prima ripristina le autorizzazioni di alcuni file. Si noti che mentre la maggior parte dei file è ora troppo aperta, ad alcuni mancano i bit setuid necessari . Ecco i passi che dovresti fare prima di ogni altra cosa. Si noti che questo non è un elenco esaustivo, solo un tentativo di rendere il sistema a malapena funzionale.

chmod -R go-w /
chmod 440 /etc/sudoers
chmod 640 /etc/shadow /etc/gshadow
chmod 600 /etc/ssh/*_key /etc/ssh*key   # whichever matches
chmod 710 /etc/ssl/private /etc/cups/ssl
chmod 1777 /tmp /var/tmp /var/lock
chmod 4755 /bin/su /usr/bin/passwd /usr/bin/sudo /usr/bin/sudoedit
chmod 2755 /var/mail /var/spool/mail

Quindi dovrai ripristinare tutte le autorizzazioni ovunque. Per i file in /usr, è possibile reinstallare i pacchetti con uno dei seguenti comandi, a seconda della distribuzione:

• Se stai usando Debian, Ubuntu o un'altra distribuzione basata su APT, puoi eseguire apt-get --reinstall install
• Se stai usando Arch Linux, puoi eseguirlo pacman -S $(pacman -Qq --dbpath /newarch/var/lib/pacman) --root /newarch --dbpath /newarch/var/lib/pacman, supponendo che tu sia in un Live CD e che l'installazione di Arch sia montata su /newarch.

Per i file in /etce /var, che non funzioneranno, molti di loro rimarranno così come sono: dovrai replicare le autorizzazioni su un'installazione funzionante. Per i file in /srve /home, dovrai comunque ripristinare dai backup. Come puoi vedere, potresti anche reinstallare.

All'inizio potresti non accorgertene, ma molte cose possono e andranno male. Il problema principale è che l'intero modello di sicurezza per l'intero sistema è rotto. È come avere un corpo senza pelle, organi in aria. È destinato a essere infettato perché non è pensato per funzionare in questo modo. Anche se sembra funzionare per alcuni minuti, è necessario ripulirlo.

Il modo migliore sarebbe effettivamente iniziare da zero. In questo modo si ridurrà notevolmente il rischio e si otterrà un risultato più pulito in meno tempo. Se si dispone di backup adeguati, questa non dovrebbe essere un'esperienza troppo impegnativa.

Se provi a ripulirlo, il modo principale sarebbe quello di dire al gestore dei pacchetti della tua distribuzione di reinstallare TUTTO sul sistema, incluso sovrascrivere i file di configurazione. Quindi utilizzare qualunque sistema di verifica sia necessario esaminarli e assicurarsi che nessuno di essi sia contrassegnato come file con autorizzazioni fuori dall'ordinario. Quindi, passa attraverso cose come le directory home degli utenti e reimposta tutto su normali autorizzazioni in massa, quindi passa attraverso le poche cose che dovrebbero avere autorizzazioni speciali (come i file ssh keys). Infine, fai una ricerca completa del sistema per tutto ciò che è contrassegnato come 777 e passa attraverso l'elenco (dovrebbe essere piccolo se hai eseguito accuratamente gli altri passaggi) e lavora uno ad uno assicurandoti che dovrebbero essere come sono.

SOLUZIONE: TESTATO QUESTO IN CENTOS

Questo ragazzo mi ha salvato il lavoro! (Devi accedere in qualche modo)

http://www.adminlinux.org/2009/07/how-to-restore-default-system.html

1) Per ripristinare uid e gid su file e directory:

for u in $(rpm -qa); do rpm --setugids $u; done

2) Alle autorizzazioni per file e directory

for p in $(rpm -qa); do rpm --setperms $p; done

quindi modificare manualmente le autorizzazioni per questi file:

# ll /etc/ssh/
# chmod 600 /etc/ssh/ssh_host_rsa_key
# chmod 600 /etc/ssh/ssh_host_dsa_key
# service sshd restart

Alcuni programmi sensibili alla sicurezza non si avviano se alcuni file hanno autorizzazioni troppo "libere". Come diceva @ceving, sshdè il più tipico di questo.

La cosa principale che può andare storto è che ora qualsiasi utente può aprire, leggere e scrivere qualsiasi file sul tuo sistema. I due motivi per cui questo è negativo è: A) se un utente malintenzionato ottiene il controllo del tuo sistema attraverso un exploit o una configurazione errata, può modificare qualsiasi cosa sul tuo sistema ora, e B) puoi eliminare tutto ciò che desideri anche se non sei root, quindi hai appena annullato la maggior parte delle protezioni di non essere eseguito come root.

Se non hai precedentemente eseguito il backup delle autorizzazioni, ti trovi in ​​una situazione un po 'problematica. Potresti essere in grado di creare uno script che "recupera" un elenco di autorizzazioni da un sistema appena installato e quindi "applica" quelle a tutto il tuo sistema. Tuttavia, non ho una sceneggiatura a portata di mano.