Perché su world è eseguibile?

Ho un server senza testa che è connesso in remoto da più utenti. Nessuno degli altri utenti si trova nel file sudoers, quindi non è possibile ottenere il root tramite sudo. Tuttavia, poiché le autorizzazioni susono -rwsr-xr-xnon c'è nulla che impedisce loro di tentare di forzare la password di root.

Si potrebbe sostenere che se un utente conosce la password di root può comunque compromettere il sistema, ma non penso che sia così. OpenSSH è configurato con PermitRootLogin noe PasswordAuthentication noe nessuno degli altri utenti ha accesso fisico al server. Per quanto ne so, il mondo esegue l'autorizzazione /usr/bin/suè l'unica strada per gli utenti che tentano di ottenere il root sul mio server.

Cosa c'è di più sconcertante per me in quanto non sembra nemmeno utile. Mi permette di correre sudirettamente invece di doverlo fare sudo su, ma questo non è certo un inconveniente.

Sto trascurando qualcosa? Il mondo sta eseguendo il permesso suproprio lì per motivi storici? Ci sono degli svantaggi nella rimozione di quell'autorizzazione che non ho ancora riscontrato?

Un punto che manca alla risposta di ilkkachu è che elevare alla radice è solo un uso specifico per su. Lo scopo generale di su è quello di aprire una nuova shell con l'account di accesso di un altro utente. L'altro utente potrebbe essere root(e forse il più delle volte lo è), ma supuò essere utilizzato per assumere qualsiasi identità che il sistema locale può autenticare.

Ad esempio, se ho effettuato l'accesso come utente jime desidero indagare su un problema mikesegnalato ma che non riesco a riprodurre, potrei provare ad accedere come mikeed eseguire il comando che gli sta causando problemi.

13:27:20 /home/jim> su -l mike
Password:(I type mike's password (or have him type it) and press Enter)
13:27:22 /home/mike> id
uid=1004(mike) gid=1004(mike) groups=1004(mike)
13:27:25 /home/mike> exit  # this leaves mike's login shell and returns to jim's
13:27:29 /home/jim> id
uid=1001(jim) gid=1001(jim) groups=1001(jim),0(wheel),5(operator),14(ftp),920(vboxusers)

L'uso -ldell'opzione di sucause simula un accesso completo (per manpagina).

Quanto sopra richiede comunque la conoscenza della mikepassword. Se ho sudoaccesso, posso accedere come mikeanche senza la sua password.

13:27:37 /home/jim> sudo su -l mike
Password:(I type my own password, because this is sudo asking)
13:27:41 /home/mike>

In sintesi, il motivo per cui le autorizzazioni sull'eseguibile susono come si vede, è perché suè uno strumento generico disponibile per tutti gli utenti del sistema.

Storicamente (su unice non GNU), non lo era, o almeno controllava manualmente se fossi in un gruppo chiamato "wheel" autorizzato su. La versione GNU di sunon riproduceva questa funzionalità a causa dell'ideologia di RMS sul controllo degli accessi all'epoca:

Why GNU `su' does not support the `wheel' group
===============================================

   (This section is by Richard Stallman.)

   Sometimes a few of the users try to hold total power over all the
rest.  For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else.  (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)

   However, occasionally the rulers do tell someone.  Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest.  The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.

   I'm on the side of the masses, not that of the rulers.  If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.

Puoi trovare molto di più sull'argomento googling "gruppo ruota rms" o simili.

Tuttavia, poiché le autorizzazioni susono -rwsr-xr-xnon c'è nulla che impedisce loro di tentare di forzare la password di root.

Sì. Supponendo che il tuo solito sistema Linux, il pam_unix.somodulo ritarda un tentativo di autenticazione fallito di ~ due secondi, ma non credo che ci sia nulla per fermare i tentativi simultanei.

I tentativi falliti sono ovviamente registrati:

Aug 16 22:52:33 somehost su[17387]: FAILED su for root by ilkkachu

La forzatura bruta di una password dovrebbe apparire in primo piano nei registri, se si dispone di un sistema per monitorarli. E se hai utenti locali non attendibili, forse dovresti. Gli utenti locali non attendibili potrebbero anche tentare di utilizzare qualsiasi exploit di escalation di privilegi solo locale e sono molto più comuni dell'escalation di privilegi remoti.

Cosa c'è di più sconcertante per me in quanto non sembra nemmeno utile.

Naturalmente è utile, ti permette di elevarti a root, se conosci la password.

Mi permette di correre sudirettamente invece di doverlo fare sudo su, ma questo non è certo un inconveniente.

sudo suè in qualche modo ridondante. Non è necessario utilizzare due programmi che consentono di eseguire programmi come un altro utente, uno è abbastanza. Basta usare sudo -io sudo -s(o sudo /bin/bashecc.) Se si desidera eseguire la shell.

Sto trascurando qualcosa? Il mondo esegue il permesso su su proprio lì per motivi storici?

Vedi sopra. Bene, non tutti i sistemi hanno sudoun'alternativa, non sono sicuro se lo consideri storico.

Ci sono degli svantaggi nella rimozione di quell'autorizzazione che non ho ancora riscontrato?

Non proprio, no per quanto ne so. Penso che alcuni sistemi siano stati suimpostati in modo che solo i membri di un determinato gruppo (" wheel") possano eseguirlo. Puoi fare lo stesso per sudose ti piace ( chown root.sudousers /usr/bin/sudo && chmod 4710 /usr/bin/sudo).

Oppure potresti semplicemente rimuovere uno o entrambi i programmi se non ti servono. Anche se su Debian, suviene fornito con il loginpacchetto, quindi probabilmente non è una buona idea rimuovere il pacchetto nel suo insieme. (E l'accoppiamento logine suinsieme così sembra un po 'storico.)

Hai già delle buone risposte, ma c'è una parte del tuo post che non affrontano.

Per quanto ne so, il mondo esegue l'autorizzazione su / usr / bin / su è l'unica strada per gli utenti che tentano di ottenere il root sul mio server.

È un presupposto pericoloso. Se hai impostato una buona password per root, nella maggior parte dei casi è molto più probabile che una escalation di privilegi riuscita sia dovuta allo sfruttamento di un bug nel kernel o di un binario setuid (puoi ovviamente rimuovere anche il setuid un po 'da quelli, ma passwdè setuid, e se vuoi una sicurezza elevata dovresti anche offrirlo ai tuoi utenti, e negando loro l'opzione di cambiare la loro password non è compatibile con quello).

su deve essere eseguibile a livello mondiale in modo che tutti possano eseguirlo. In molti sistemi, può essere utilizzato per passare a un altro utente, fornendo la propria password.

Se sei preoccupato per qualcuno che sta forzando la password di root, potresti semplicemente disabilitarla. (rendere l'hash non valido in modo che nessuna password data possa corrispondere)

Non conosco il consenso, ma prenderei in considerazione la possibilità di accedere direttamente come root come un problema di sicurezza in sé e per sé.

Le altre risposte sono corrette dicendo che "su" consente di accedere ad account diversi da root.

Una nota su "sudo su" però. Questo in realtà ti consente di accedere all'account di root senza conoscere la password di root. Devi conoscere la password dell'account con cui esegui sudo e avere quell'account nel file sudoers.