Por que o Linux não permite permissões de porta de rede no nível do usuário? [fechadas]

De vez em quando, procurarei como fazer permissões no nível do usuário para acesso à porta de rede no Linux e me tornarei um tanto seco. Por exemplo, se você tem uma máquina que executa um processo crítico que escuta na porta 5080, acho que deve haver uma maneira de conceder a apenas um conjunto específico de usuários confiáveis ​​acesso a essa porta - assim como qualquer outro processo de permissões sãs é feito, como permissões do sistema de arquivos.

Mas parece que portas altas estão disponíveis para todos os usuários, e portas baixas estão disponíveis apenas para o root, com apenas hacks brutos como authbind e encaminhamento com iptables para permitir que outros usuários usem portas baixas. Parece uma situação muito estranha, então eu estou me perguntando, por que foi projetado dessa maneira e por que as pessoas não sentiram a necessidade de mudar essa situação?

O Linux suporta namespaces de rede. Você pode fazer com que processos diferentes vejam conjuntos diferentes de interfaces de rede. Este é um tópico amplo.

Se você deseja uma porta de comunicação acessível dentro da máquina apenas a usuários específicos, pode usar um soquete Unix tradicional, que possui um nome no espaço do sistema de arquivos com permissões. O Linux respeita as permissões de leitura / gravação nos soquetes AF_UNIX.

Se uma máquina ouvir solicitações externas de TCP ou UDP na porta 5080 que chegam de outras máquinas, não poderemos mais falar sobre permissões de usuário . Você precisa criar segurança no protocolo que ultrapassa o 5080: autenticação, criptografia, integridade / prova de falsificação / resistência a dos.

Inicialmente, eu acho, porque exigiria um design complexo que estivesse fora de linha com o escopo dos primeiros sistemas Unix.

Mais tarde, acho, porque havia uma maneira estabelecida de implementar permissões de porta de rede no nível do usuário para casos comuns: inetd , que apareceu alguns anos depois do TCP / IP ( 4.3BSD ) ( 4.2BSD ). O inetddaemon é executado como root e escuta as portas especificadas em seu arquivo de configuração. Em uma conexão de entrada, inetdgera outro programa especificado em seu arquivo de configuração e é executado como um usuário também especificado no arquivo de configuração inetd. Portanto, pelo menos para os serviços em que é aceitável iniciar um novo processo em cada conexão, o problema está resolvido.

Eu acho que um dos motivos é que a maioria dos usuários precisa usar portas efêmeras para se conectar a outros servidores, sem necessariamente ser root.

Uma conexão TCP / IPv4 consiste em dois pontos finais, e cada ponto final consiste em um endereço IP e um número de porta. Portanto, quando um usuário cliente se conecta a um computador servidor, uma conexão estabelecida pode ser considerada como a tupla de quatro (IP do servidor, porta do servidor, IP do cliente, porta do cliente). Geralmente, três dos quatro são facilmente conhecidos - a máquina cliente usa seu próprio endereço IP e, ao conectar-se a um serviço remoto, é necessário o endereço IP e o número da porta de serviço da máquina servidor.

O que não é imediatamente evidente é que, quando uma conexão é estabelecida, o lado do cliente usa um número de porta. A menos que um programa cliente solicite explicitamente um número de porta específico, o número da porta usado é um número de porta efêmero. Portas efêmeras são portas temporárias atribuídas pela pilha IP de uma máquina e são atribuídas a partir de um intervalo designado de portas para essa finalidade. Quando a conexão termina, a porta efêmera está disponível para reutilização, embora a maioria das pilhas IP não reutilize esse número de porta até que todo o conjunto de portas efêmeras tenha sido usado. Portanto, se o programa cliente se reconectar, será atribuído um número de porta efêmero diferente para o lado da nova conexão.