Почему Linux не разрешает права доступа к сетевому порту на уровне пользователя? [закрыто]

Время от времени я буду искать, как сделать разрешения на уровне пользователя для доступа к сетевым портам в Linux, и получаю довольно сухо. Например, если у вас есть машина, которая выполняет критический процесс, который прослушивает порт 5080, я чувствую, что должен быть способ предоставить доступ только к определенному набору доверенных пользователей к этому порту - так же, как и любой другой нормальный процесс разрешений. сделано, как разрешения файловой системы.

Но кажется, что высокие порты доступны для всех пользователей, а низкие порты доступны только для root, и только грубые хаки, такие как authbind и пересылка с iptables, позволяют другим пользователям использовать низкие порты. Кажется, что это очень странная ситуация, поэтому мне интересно, почему она была разработана таким образом и почему люди не чувствовали необходимости менять эту ситуацию?

Linux поддерживает сетевые пространства имен. Вы можете заставить разные процессы видеть разные наборы сетевых интерфейсов. Это широкая тема.

Если вы хотите, чтобы коммуникационный порт был доступен в машине только для определенных пользователей, вы можете использовать традиционный сокет Unix, который имеет имя в пространстве файловой системы с разрешениями. Linux уважает права на чтение / запись для сокетов AF_UNIX.

Если машина прослушивает внешние TCP или UDP-запросы на порт 5080, поступающие с других машин, мы больше не можем говорить о правах пользователя . Вы должны встроить безопасность в протокол, превышающий 5080: аутентификация, шифрование, защита целостности / защита от подделки / защита от несанкционированного доступа.

Изначально, я думаю, потому что это потребовало бы сложного дизайна, который не соответствовал бы ранним системам Unix.

Позже, я думаю, потому что существовал способ реализации разрешений сетевого порта на уровне пользователя для общих случаев: inetd , который появился примерно через пару лет после ( 4.3BSD ) TCP / IP ( 4.2BSD ). inetdДемон работает как корень и прослушивает порты , указанные в файле конфигурации. При входящем соединении inetdпорождает другую программу, указанную в его файле конфигурации и выполняющуюся как пользователь, также указанный в файле конфигурации inetd. Таким образом, по крайней мере для служб, в которых допустимо запускать новый процесс для каждого соединения, проблема решена.

Я думаю, что одной из причин является то, что большинство пользователей должны иметь возможность использовать временные порты для подключения к другим серверам, не обязательно являясь пользователем root.

Соединение TCP / IPv4 состоит из двух конечных точек, и каждая конечная точка состоит из IP-адреса и номера порта. Поэтому, когда пользователь клиента подключается к компьютеру-серверу, установленное соединение может рассматриваться как набор из 4 (IP-адрес сервера, порт сервера, IP-адрес клиента, клиентский порт). Обычно три из четырех общеизвестны - клиентский компьютер использует свой собственный IP-адрес, а при подключении к удаленному сервису требуются IP-адрес серверного компьютера и номер порта сервиса.

Что не сразу видно, так это то, что когда соединение установлено, клиентская сторона соединения использует номер порта. Если клиентская программа явно не запрашивает конкретный номер порта, используемый номер порта является эфемерным номером порта. Эфемерные порты - это временные порты, назначаемые IP-стеком машины, и назначаются для этого назначенным диапазоном портов. Когда соединение завершается, эфемерный порт доступен для повторного использования, хотя большинство стеков IP не будет повторно использовать этот номер порта, пока не будет использован весь пул эфемерных портов. Таким образом, если клиентская программа повторно подключится, ей будет назначен другой эфемерный номер порта для ее стороны нового соединения.