C'è un modo per impedire ai sudoers di modificare cose in / etc / ssh / sshd_config?

In definitiva, le blacklist non funzionano : sarebbe uno sforzo inutile cercare di trovare tutti i modi con cui un utente root-equivalent potrebbe modificare il contenuto di /etc/ssh/sshd_config e provare a risolverli tutti. Ad esempio, molti comandi possono generare alcuni dati in un file il cui nome è fornito come parametro, che potrebbe essere usato per modificare /etc/ssh/sshd_config .

Invece, utilizza le whitelist : concedi esplicitamente ai sudoer di eseguire un insieme di comandi espliciti, piccoli (ad esempio un comando per attivare un riavvio, se questo è pertinente alla tua situazione) e tutto altri devono essere vietati.

In alternativa, usa SELinux per vincolare sudoers in un ruolo non esattamente root e ottieni /etc/ssh/sshd_config out della loro portata. Ma questo può comportare un considerevole lavoro di configurazione (SELinux sembra essere all'altezza del compito, ma non l'ho provato, quindi non garantisco il successo qui). Inoltre, si tenga presente che il potere del fastidio di un utente root-root tende a essere pervasivo: ci sono molti molti modi con cui un utente del genere può danneggiare la sicurezza. Sembra meglio non fidarsi solo delle persone malvagie con poteri sudo. Oppure potrebbe essere giustificato un livello di isolamento più completo: invece di avere più utenti in una singola macchina, con alcuni poteri semi-amministrativi, dare una macchina virtuale a ciascun utente, che può giocare a piacimento senza influenzare gli altri utenti. A seconda del contesto, questo potrebbe o potrebbe non essere applicabile.

Il più vicino che riuscirai a rendere impossibile è usare un insieme estremamente ristretto di ciò che è possibile con sudo. Dovrai vietare l'accesso a vi, editor, shell e su. È meglio cercare di determinare quali comandi sono necessari e sperare che nessuno di loro abbia la possibilità di modificare file o directory o eseguire comandi.

In definitiva se concedi a qualcuno dei privilegi sul tuo sistema, stai invocando dei rischi.

Ci sono altre alternative che puoi prendere in considerazione:

Controlla i log SSH per i login di root con password auth. Questo è il tuo indicatore principale che il tuo file è stato modificato.

Monitora quel file per le modifiche con un cron in esecuzione frequente. Se qualcuno modifica quel file e non nota il monitor, lo prendi.

Sì , con AppArmor potrebbe essere possibile:

Ho provato in qualche modo a usare MAC (controllo obbligatorio degli accessi) e l'AppArmor LSM (modulo di sicurezza linux) e ho scoperto che potreste avere una modifica usando AppArmor per rendere /etc/ssh/sshd_config impossibile da scrivere usando sudo .

Questo profilo AppArmor limita ciò che l'utente può fare dopo aver acquisito "potenza di root" tramite sudo

/usr/bin/sudo {
  capability setgid,
  capability setuid,
  / rw,
  /** rwmix,
  deny /etc/ssh/sshd_config w,
  deny /usr/sbin/aa* rw,
  deny /sbin/app* rw,
  deny /usr/bin/sudo rw,
  deny /etc/apparmor.d/profile.usr.bin.sudo rw,
  deny /sys/kernel/security/apparmor/ rw,
  deny /sys/kernel/security/apparmor/** rw,
}

Per sicurezza, prima cerca se esiste già un profilo AppArmor preesistente per /usr/bin/sudo

$ aa-status | grep sudo

Nel caso in cui non ci sia nessuno, l'output è vuoto! Se non sei vuoto, dovresti parlare meglio con quei ragazzi che hanno impostato il profilo e non andare qui.

Se - come previsto - non esiste ancora un profilo, puoi crearne uno con questo comando:

root@computer:/root/# echo "/usr/bin/sudo {
>   capability setgid,
>   capability setuid,
>   / rw,
>   /** rwmix,
>   deny /etc/ssh/sshd_config w,
>   deny /usr/sbin/aa* rw,
>   deny /sbin/app* rw,
>   deny /usr/bin/sudo rw,
>   deny /etc/apparmor.d/profile.usr.bin.sudo rw,
>   deny /sys/kernel/security/apparmor/ rw,
>   deny /sys/kernel/security/apparmor/** rw,
> } " > /etc/apparmor.d/yourprofile.usr.bin.sudo

Quindi puoi avviare / configurare il nuovo profilo

root@computer:/root/# apparmor_parser -r /etc/apparmor.d/yourprofile.usr.bin.sudo
root@computer:/root/# aa-enable /etc/apparmor.d/yourprofile.usr.bin.sudo

come risultato per un utente questo dovrebbe essere il risultato:

ssh_user@computer:~$ sudo bash -c "echo 'PermitRootLogin yes' >> /etc/ssh/sshd_config"
[sudo] password for ssh_user: 
bash: /etc/ssh/sshd_config: Permission denied
ssh_user@computer:~$ sudo -i
root@computer:/root/$ echo 'PermitRootLogin yes' >> /etc/ssh/sshd_config
-bash: /etc/ssh/sshd_config: Permission denied
root@computer:/root/$ aa-disable profile.usr.bin.sudo
Can't open perl script "/usr/sbin/aa-disable": Permission denied

Purtroppo non posso darti informazioni su come implementarlo in altri LSM come SELinux o grsecurity.

Comunque gradirei ricevere un feedback se la soluzione ti ha aiutato:)

Tieni presente che i limiti relativi a ciò che può essere fatto con sudo sono per tutti e questo significa che se usi sudo per ottenere il superuserpot subirai gli stessi limiti (cioè non puoi disabilitare apparmor, né /etc/ssh/sshd_config te stesso. Solo uno che può è una vera radice tramite login.

Potresti scrivere il tuo / etc / ssh / sshd_config in un'unità di sola lettura fisica. In tal caso, anche se si è effettuato il login come root, non è possibile modificare sshd_config.

Ma allora dovresti stare attento a

• se l'utente può montare e smontare le unità, potrebbe semplicemente smontare l'unità su cui è presente sshd_config
• se l'utente ha accesso fisico alla tua macchina, allora potrebbe semplicemente sostituire il disco