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

Question

De vez em quando, procurarei como fazer permissões em nível de usuário para acesso à porta de rede no Linux e ficar um pouco seco. Por exemplo, se você tem uma máquina que executa um processo crítico que escuta na porta 5080, sinto que deve haver uma maneira de dar a um determinado conjunto de usuários confiáveis acesso a essa porta - da mesma forma que qualquer outro processo de permissão sã é feito, como permissões do sistema de arquivos.

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

    

Answer 1

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

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

Se uma máquina escuta solicitações TCP ou UDP externas na porta 5080 que chegam de outras máquinas, não podemos mais falar sobre as permissões usuário . Você precisa criar segurança no protocolo que está ultrapassando 5080: autenticação, criptografia, integridade / spoof-proofing / dos-resistance.

    

Answer 2

Inicialmente, eu acho, porque seria necessário um design complexo que estivesse fora de sintonia com o escopo dos primeiros sistemas Unix.

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

    

Answer 3

Acho que uma das razões pelas quais a maioria dos usuários precisa ser capaz de usar portas efêmeras para conectar para outros servidores, sem necessariamente ser root.

A TCP/IPv4 connection consists of two endpoints, and each endpoint consists of an IP address and a port number. Therefore, when a client user connects to a server computer, an established connection can be thought of as the 4-tuple of (server IP, server port, client IP, client port). Usually three of the four are readily known -- client machine uses its own IP address and when connecting to a remote service, the server machine's IP address and service port number are required.

What is not immediately evident is that when a connection is established that the client side of the connection uses a port number. Unless a client program explicitly requests a specific port number, the port number used is an ephemeral port number. Ephemeral ports are temporary ports assigned by a machine's IP stack, and are assigned from a designated range of ports for this purpose. When the connection terminates, the ephemeral port is available for reuse, although most IP stacks won't reuse that port number until the entire pool of ephemeral ports have been used. So, if the client program reconnects, it will be assigned a different ephemeral port number for its side of the new connection.