appropriateness of requiring registration of ports in /etc/services

ta0kira · 10-30-2008, 02:22 PM

A part of one of my projects has an option that allows a user to specify a port to bind a server to. I plan to require the port to be one registered on the system, i.e. in /etc/services (checked via getservbyport,) before the program accepts it, but not until the project reaches a stable release (to allow for testing until then.)

The purpose of the server is to forward IPC from one "my project" system to another; nothing else (the "server" isn't actually the server in the project, but it acts as one in the context of this post.) The client and server making a connection are the exact same program, but one binds and one connects based on their particular contexts.

My reasoning behind requiring registered ports is that having that built in will assure anyone running a particular system that root has somehow approved the port binding (or the server will obviously be bound to another service's port.) The client/server program will fail to function if run as root; therefore, it won't work to require binding to a <1024 port. Is this an unreasonable or superfluous inconvenience to impose? I'm sure it would be more effective to require that the service itself have a specific name (or match a regex,) but this is a generic application framework, so several differently-purposed applications may exist at one time on the same system. Thanks.
ta0kira

PS I'm leaning toward requiring service name regex match at this point.

Hko · 10-30-2008, 04:02 PM

Quote:

Originally Posted by ta0kira

Is this an unreasonable or superfluous inconvenience to impose?

Maybe not unreasonable or superfluous, but it will be a (small) inconvenience anyway. The thing that I don't like about it is that I've never seen a program doing that and from the man page "services(5)" I get the impression that is meant for IANA assgined port numbers only.

Wouldn't it be more convenient/correct if your program just requires it's configuration file to be in /etc? If the program doesn't need a configuration file at all, you could even make it an empty file just for the purpose of checking root approved the program on the machine. This can also be made automatic at install time more easily.

Another approach could be the other way around: require that root runs it. If needed, the program can drop root privileges as the first thing it does.

Also keep in mind that how ever you do it, it will be easy to get around the check, one only would need a compiler.. (if the source will be available that is)

ta0kira · 10-30-2008, 09:37 PM

Quote:

Originally Posted by Hko

Wouldn't it be more convenient/correct if your program just requires it's configuration file to be in /etc? If the program doesn't need a configuration file at all, you could even make it an empty file just for the purpose of checking root approved the program on the machine. This can also be made automatic at install time more easily.

It isn't a configuration-stage only option, though, and the network program has a local-socket counterpart which I don't want restricted. They need to remain 100% interchangable aside from using IP:port addresses for one and filename addresses for the other. This is so prototyping can be done using local sockets, with future conversion to network sockets being trivial.

Quote:

Originally Posted by Hko

Another approach could be the other way around: require that root runs it. If needed, the program can drop root privileges as the first thing it does.

It's actually the method of process creation that prevents it from running as root (the program also performs extra checks.) It's difficult to explain, but basically this program acts as an agent for a daemonized local-machine server to protect the server itself from outside influence. The local-machine server is completely isolated from the user and almost completely isolated from the file system, networks, and devices. It spawns all of its own client processes, one of which can be this network program I'm talking about, and it only interacts with those processes. The local-machine server will never, under any circumstances, spawn a root process even temporarily because it can "trust itself" to run as root, but nothing else. Most of the processes it spawns will be third-party programs intended for use with the system, so my security policy is to mitigate the associated risk as much as possible.

Quote:

Originally Posted by Hko

The thing that I don't like about it is that I've never seen a program doing that and from the man page "services(5)" I get the impression that is meant for IANA assgined port numbers only.

You might be right.

Quote:

Originally Posted by Hko

Also keep in mind that how ever you do it, it will be easy to get around the check, one only would need a compiler.. (if the source will be available that is)

You are entirely correct. Most of the security is contained within the local-machine server, so it's policies like not spawning root processes that mitigates this risk. I would, however, like the other included programs (this network program being one of them) to have security precautions, as well, though.

Your /etc idea actually gave me an idea.

Here's an explanation of how the network program will start and interface with the local-machine server in general (as it is now):

A user (probably root) will start the local-machine server, providing an "execute" specification for the network program in its configuration.
The local-machine server will spawn a new non-root process and execv the network program. The local-machine server will maintain IPC with the new process.
The local-machine server's configuration will optionally be able to set the server up so that other users can indirectly interface with the server, part of which would allow those users to instruct the network program to bind to a port.
Because the starter of the server knows they started it with the project-included network program, they can trust this interaction to the extent they can trust my source code. As of now this is a very reliable program, but the ability to arbitrarily bind to ports isn't very secure.

So my idea now (based on your suggestion) is to allow specification of an "allowed ports" table to the network program. A fixed file requirement for the program will never work with the philosophy of the project, but allowing some sort of per-instance restrictions would definitely work (I already allow specification of encryption/IP-filter plug-ins.) Thanks for the idea!
ta0kira

PS I think I'll actually make it regex-based since most of the rest of the project is, and maybe integrate it with the start-up configuration.

ta0kira · 11-01-2008, 02:47 AM

It wasn't that much work to add configuration options to restrict the ports allowed to bind to. I made the specification method a combination of allowed and required expression sets, where all ports being bound to must match at least one of the allowed expressions and all of the required expressions. It's the same system for connections (where there are IP:port pairs.) For example (! inverts the requirement of the expression):

Code:

listen_require "^[0-9]{5}$"
listen_require "^[1-2]"
listen_allow "^10"
listen_require "!000$"

This would mean that all ports must be 5 digits starting with 1 or 2, and of those anything beginning with 10 is allowed, except those ending in 000. It's much more illustrative with connections because the expressions can include server names instead of just IP addresses. The prospective ports or addresses are checked both before and after DNS/service lookup. Thanks again for the idea!
ta0kira

pinniped · 11-01-2008, 03:06 AM

It's not a bad idea, but really it will only work if you are distributing binary executables. If you distribute source code, people will just tear out the bits which they see as an inconvenience. The "services" file essentially just lists IANA assigned ports; I think it's mostly useful for programs like inetd to use to refer to, but really you cannot expect this file to be used to enforce anything. If an admin wants to run a service on a different port, the services file can always be altered as appropriate (however, this is a nuisance because a software upgrade may replace the file with an updated version using information from IANA).

ta0kira · 11-01-2008, 04:29 AM

I do see your point about the hacking thing, but my angle is this: root will install my package, so "it" will know that the installation is untainted. Because of this, a user will know that when they run my network application it will have security precautions built in, meaning they can trust that their specifications will be followed by the program when other programs or users make requests of it ("mom says I can only connect to port 2048!") It isn't so much protection of the ports as it is protection of the application behind it. If a user wants to hack the source code then they can endanger their own instance of an application all they want, but a security-minded user will be able to protect their particular application instance from negligent (or hostile) influence so long as they run it from a standard path. My program is a mama's boy, but if someone wants to clone it and corrupt it to cause mischief, mine will still do the right thing! Remember, I'm securing the process via the program that the user relies upon, not the actual abilities of the binary (i.e. to secure the process, run my binary.)
ta0kira

Tinkster · 11-01-2008, 01:05 PM

But as has been pointed out (repeatedly): services is
a mere look-up for matching of well-known ports to
well-known names. For your intents and purposes I
think you'd be best off to use a file that only your
program uses.

Cheers,
Tink

ta0kira · 11-01-2008, 06:22 PM

Yes, the services discussion ended at post 3 (at least from my end, at which point I expressed my solution to the problem, although service names will still be allowed.)
ta0kira