linux-kernel - Re: /proc/sys/net/ipv4/ip_local_reserved

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 16 Sep 2011 00:21:36 -0400
From:	David Bein <d.bein@...com>
To:	<linux-kernel@...r.kernel.org>
Subject: Re: /proc/sys/net/ipv4/ip_local_reserved_ports

For the reserved port bitmap to be truly useful, there needs to be a way to
have the kernel bind (+ implicit bind in connect, datagram sendmsg, etc)
be told to use a "privileged" port range.

Has anyone ever considered adding the IP_PORTRANGE socket option
which would add 2 other port ranges: LOW (privileged -- e.g. 600-1023)
and HIGH (for high end ports, e.g. 55000-65535) for running around 
firewalls.
This interface was added to FreeBSD maybe 15 years ago and in practical
terms means that glibc bindresvport() would select the privileged port 
range,
set sin->sin_port to 0 and lets the kernel do the rest. Similar dance 
for AF_INET6.

This does require tweaking glibc bindresvport() to handle the details.
The FreeBSD folks have the details in their versions of libc.
It is in fact faster because in the presence of a number of busy ports
the overhead of a few hundred bind() system calls is eliminated.
The kernel is very good at picking free ports, so this is just extending
where it does it without hacking ip_local_port_range to include
privileged ports (which IMO is a very bad idea).

I've prototyped the kernel ip socket option support for IP_PORTRANGE
(along with the sysctl glue for 2 more port ranges).

Using this and ip_local_reserved_ports, it is indeed possible to use
the reserved ports set in the bitmap and prevent all the usual problems
when some program innocently picks a privileged port that some other
daemon will expect to be free for a specific binding on a well known port.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/