4

I'd like to restrict a range of udp ports to a single application (or a user). What I'd like to achieve is not simply blocking a bind() from other uids, but also remove the range from a pool that can be auto-assigned.

For example, if someone tries to explicitly bind 12345, but doesn't run the specified app, they should get EPERM. If someone tries to bind an unspecified port, they should never try to bind 12345 at random.

Is there any system that can help here? I tried browsing apparmor / selinux docs, but they seem to do the blocking part only.

John Gardeniers
  • 27,262
  • 12
  • 53
  • 108
viraptor
  • 1,264
  • 6
  • 21
  • 40
  • You may want to remove the 'bind' tag, as most people will expect to find a question tagged with 'bind' to be about the Bind nameserver. – wzzrd Jul 03 '09 at 12:07
  • 1
    Don't put tag-like things in the title, that's what tags are for. – Paul Tomblin Jul 03 '09 at 13:16

3 Answers3

5

The easiest way to do this on Linux is if you reserve a chunk at the top or bottom range of the standard ephemeral port range.

Find out what your current range is by running

cat /proc/sys/net/ipv4/ip_local_port_range

Then set it by echoing something different into it (and modifying sysctl.conf or similar to make it happen on boot as well). My system uses 32768-61000, so I could change that to 32768-60000 in conjunction with SELinux/AppArmor to reserve 60001-61000 for my application.

echo "32768 60000" > /proc/sys/net/ipv4/ip_local_port_range

I'm not aware of a way to carve out a gap in the middle of the ephemeral range.

James F
  • 6,549
  • 1
  • 25
  • 23
0

Install portreserve and then only your program that requests them via portrelease can have the sockets.

Curtis Doty
  • 476
  • 1
  • 5
  • 6
0

Have a look at portreserve utility. But the actual service must ask portreserve to release the port before the service can use it.

Saurabh Barjatiya
  • 4,643
  • 2
  • 29
  • 34
  • Does this work for ports outside of the range that bindresvport() uses (i.e. 0-1023)? The technique might work more generally though, but it's not quite what the OP was asking for (preventing the OS from giving out a port in a given range as opposed to starting something early to "squat" on the port range until told to release it) – James F Jul 03 '09 at 15:52
  • I just tested it for 2000/tcp and it is working. So I guess it would work for any port. It wont be very practical for reserving very large ranges, but for one or two ports here and there it is good enough. Best thing about it is it being extremely simple. – Saurabh Barjatiya Jul 03 '09 at 17:22