8

Every once in a while, I'll search for how to do user-level permissions for network port access in Linux and come up rather dry. For example, if you have a machine that runs a critical process that listens on port 5080, I feel like there should be a way to give only a particular set of trusted users access to that port – just like how any other sane permissions process is done, like filesystem permissions.

But it seems like high-ports are available to all users, and low ports are available only to root, with only crude hacks like authbind and forwarding with iptables to allow other users to use low ports. It seems like a very weird situation, so I'm wondering, why was it designed that way and why people haven't felt a need to change that situation?

closed as primarily opinion-based by EightBitTony, Scott, Jeff Schaller, garethTheRed, Michael Homer Jan 30 '16 at 8:59

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

4

Linux supports network namespaces. You can make different processes see different sets of network interfaces. This is a broad topic.

If you want a communication port that is accessible within the machine to specific users only, you can use a traditional Unix socket, which has a name in the filesystem space with permissions. Linux honors read/write permissions on AF_UNIX sockets.

If a machine listens to external TCP or UDP requests on port 5080 arriving from other machines, then we cannot really speak about user permissions any more. You have to build security into the protocol that is going over 5080: authentication, encryption, integrity/spoof-proofing/dos-resistance.

  • Do network namespaces allow different users to have access to different namespaces which in essence could all the user of some ports and block others? – B T Jan 13 '16 at 4:08
2

Initially, I guess, because it would have required a complex design that was out of line with the scope of early Unix systems.

Later, I guess, because there was an established way of implementing user-level network port permissions for common cases: inetd, which appeared about a couple of years after after (4.3BSD) TCP/IP (4.2BSD). The inetd daemon runs as root and listens on ports specified in its configuration file. Upon an incoming connection, inetd spawns another program specified in its configuration file, and which runs as a user also specified in the inetd configuration file. So, at least for services where it is acceptable to start a new process on each connection, the problem is solved.

  • Interesting. I have to say, that's such a linux thing to do to make a solution where every action requires a new process. – B T Jan 14 '16 at 21:46
0

I think one reason is most users need to be able to use ephemeral ports for connecting to other servers, without necessarily being 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.

  • 1
    How would user-level network permissions prevent that? – B T Jan 13 '16 at 20:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.