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]
Message-ID: <4E72CED0.1020200@f5.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ