Perché Linux non consente autorizzazioni per le porte di rete a livello di utente? [chiuso]

Ogni tanto cercherò come fare le autorizzazioni a livello di utente per l'accesso alle porte di rete in Linux e ne uscirò piuttosto secco. Ad esempio, se si dispone di una macchina che esegue un processo critico in ascolto sulla porta 5080, ritengo che dovrebbe esserci un modo per dare a un determinato gruppo di utenti attendibili l'accesso a quella porta, proprio come qualsiasi altro processo di autorizzazioni sano di mente fatto, come le autorizzazioni del filesystem.

Ma sembra che le porte alte siano disponibili per tutti gli utenti e le porte basse siano disponibili solo per il root, con solo hack rozzi come authbind e forwarding con iptables per consentire ad altri utenti di usare porte basse. Sembra una situazione molto strana, quindi mi chiedo, perché è stato progettato in quel modo e perché le persone non hanno sentito il bisogno di cambiare quella situazione?

Linux supporta gli spazi dei nomi di rete. È possibile fare in modo che processi diversi visualizzino diversi set di interfacce di rete. Questo è un argomento ampio.

Se si desidera una porta di comunicazione accessibile all'interno della macchina solo a utenti specifici, è possibile utilizzare un socket Unix tradizionale, che ha un nome nello spazio del filesystem con autorizzazioni. Linux onora le autorizzazioni di lettura / scrittura sui socket AF_UNIX.

Se una macchina ascolta le richieste TCP o UDP esterne sulla porta 5080 in arrivo da altre macchine, non possiamo più parlare delle autorizzazioni dell'utente . Devi integrare la sicurezza nel protocollo che supera i 5080: autenticazione, crittografia, integrità / impermeabilità allo spoofing / resistenza ai dos.

Inizialmente, suppongo, perché avrebbe richiesto un design complesso che era fuori linea con l'ambito dei primi sistemi Unix.

Più tardi, immagino, perché esisteva un modo consolidato di implementare le autorizzazioni delle porte di rete a livello di utente per i casi comuni: inetd , che appariva circa un paio di anni dopo ( 4.3BSD ) TCP / IP ( 4.2BSD ). Il inetddemone viene eseguito come root ed è in ascolto sulle porte specificate nel suo file di configurazione. Su una connessione in entrata, inetdgenera un altro programma specificato nel suo file di configurazione e che viene eseguito come utente specificato anche nel file di configurazione inetd. Quindi, almeno per i servizi in cui è accettabile avviare un nuovo processo su ogni connessione, il problema è risolto.

Penso che uno dei motivi sia che la maggior parte degli utenti deve essere in grado di utilizzare porte effimere per connettersi ad altri server, senza essere necessariamente root.

Una connessione TCP / IPv4 è composta da due endpoint e ciascun endpoint è costituito da un indirizzo IP e un numero di porta. Pertanto, quando un utente client si connette a un computer server, una connessione stabilita può essere considerata come la 4 tupla di (IP server, porta server, IP client, porta client). Di solito tre dei quattro sono prontamente noti: la macchina client utilizza il proprio indirizzo IP e quando si collega a un servizio remoto, sono richiesti l'indirizzo IP e la porta del servizio della macchina server.

Ciò che non è immediatamente evidente è che quando viene stabilita una connessione che il lato client della connessione utilizza un numero di porta. A meno che un programma client non richieda esplicitamente un numero di porta specifico, il numero di porta utilizzato è un numero di porta temporaneo. Le porte temporanee sono porte temporanee assegnate dallo stack IP di una macchina e sono assegnate da un intervallo designato di porte per questo scopo. Al termine della connessione, la porta temporanea è disponibile per il riutilizzo, sebbene la maggior parte degli stack IP non riutilizzerà quel numero di porta fino a quando non sarà stato utilizzato l'intero pool di porte temporanee. Quindi, se il programma client si riconnette, gli verrà assegnato un numero di porta temporaneo diverso per il suo lato della nuova connessione.