LWN: Comments on "KPortReserve and the multi-LSM problem"

KPortReserve and the multi-LSM problem

mstone_ — Wed, 21 Aug 2013 15:58:39 +0000

The reason for the restriction on low numbered ports doesn't have anything to do with "importance", it has to do with a simple mechanism to verify that a particular connection originated from a privileged process (assuming a trusted network). This is extremely important in, e.g., an old-school NFS environment, as the use of the privileged port is the only thing that prevents unprivileged users from making privileged connections to the NFS server. The same sort of model was used for rsh and some other protocols.

Obviously, in the modern world you'd want to depend on some sort of strong authentication rather than origin port, especially if you're on a trusted network which mixes traditional unix systems with other systems which don't enforce privileged ports or any untrusted network. Nevertheless, as long as people use linux to interoperate with legacy environments it's useful to retain this now-obsolete functionality. It's also useful to understand this model if you run a legacy NFS environment--I've even seen some vendors who have forgotten, and shipped NFS configurations which permitted any user on an NFS client to read any file on an NFS server (scary, and exploited). And if you create any new protocol which depends on this property, you're an idiot. :)

KPortReserve and program-name based port assignments

giraffedata — Fri, 16 Aug 2013 22:34:57 +0000

He sure didn't make his point that making permissions based on the program is better than making them based on the uid (or anything else).

I should be able to run 10 web servers all running Apache, with each entitled to its own unique port. If I have to vary some attribute to give them different port permissions, I'd much rather give the processes different uids than give Apache different names.

I find altogether too much conflating of programs with services.

And I especially didn't get why being 21st century thinking makes it bad.

unprivileged access to reserved network ports

giraffedata — Fri, 16 Aug 2013 22:28:10 +0000

i.e. given users can bind to low ports. Mail servers, web server, dns server, need not run as root even for an instant. Just startup and bind to their standard port. No dropping permissions, ...

I suppose it's because people think something based on a superuser process is more consistent with Unix overall, more flexible, less work, etc. I do.

Other operating systems were designed to have a variety of permission lists, for a variety of fixed kinds of permissions, which is what you're describing, but Unix designers thought it was superior just to have one basic permission: superuser. Coupled with the setuid flag, that meant application developers could implement an unimaginable variety of permission schemes just by writing code.

In retrospect, we know that that flexibility creates no end of opportunity for accidentally granting too much permission, but the engineering simplicity of it is still appealing.

I personally don't like having a server program drop permissions because it means I have to trust the program to drop the permissions, and have duplicate code in every server program. But I do a similar thing where a single program dedicated to binding ports binds the port, drops permissions, then execs the server program (actually, teh binder execs a program that sets permissions and that program execs the server program).

That port binder program could easily be setuid superuser and consult a file such as you propose, but I haven't found that maintaining such a file would be preferable to maintaining the scripts that invoke it, which contain the same information.

KPortReserve and the multi-LSM problem

jwarnica — Thu, 15 Aug 2013 22:25:49 +0000

It isn't entirely related to this, and its not clear if this would solve my oft-pondered "WTF doesn't this exist"?

<=1024 is reserved, based on historical reasons, for root-executed processes. Allegedly, this is because important things run <=1024 and non-important things don't, and this hysterical, er, historical, conclusion fails to pass any sniff test of sanity. There are lots of hosts out their with out any meaningful concept of users; with more granularity in their admin/not distinctions than unix; or less (including Linux appliances that run everything as root)

So taking some widely used apps, with their own user id's, why _isn't_ there a file thus:

/etc/portsec
25:smtp
53:named
80:wwwrun
631:cups

i.e. given users can bind to low ports. Mail servers, web server, dns server, need not run as root even for an instant. Just startup and bind to their standard port. No dropping permissions, no master socket listener waiting to pass things off to a low privilege thread. Just run as whoever and bind to what you are allowed to (at least for <=1024).