Summary: | [tun] Closing tun<n> interface deconfigures IP address | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | jphartmann | ||||
Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
Status: | Open --- | ||||||
Severity: | Affects Only Me | CC: | seth.hoffert | ||||
Priority: | Normal | ||||||
Version: | Unspecified | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
jphartmann
2013-12-20 11:20:01 UTC
Perhaps I should describe my application. I wish to configure a tun device at boot with an IP address and chown the corresponding /dev/tun file to the userID that will use it running Hercules. The other end of the tunnel is an IBM System/360 channel-to-channel adapter. I would like to be able to restart Hercules without having to issue commands (or ioctl()s) that require root privileges. Hercules ships a setuid program, hercifc, to set interface parameters by ioctl(). I am required to be rid of this trojan horse. Thanks, j. The error was introduced by http://www.freebsd.org/cgi/query-pr.cgi?pr=100080 Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s). For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped Created attachment 198393 [details]
Proposed patch
I took a stab at patching tun to bring it into parity with tap. In line with tap behavior, it will check for the IFF_LINK0 flag on the interface. If present, it will persist the IPs and routes even when the device node is closed.
In addition to the use case listed in earlier comments, this makes IP-aliased jail interaction with tun nicer in that processes within the jail (e.g. OpenVPN) can be bounced without having to restart the jail or externally reconfigure IPs/routes on the tun.
Thank you. The current behaviour actually has a security issue as a non-privileged user can cause reconfiguration, i.e., remove the ip address from the interface. E.g., (from a linux system where this bug arrived some five years ago): openvpn --mktun --dev tun4 --user john --group john ifconfig tun4 up 10.0.0.32/30 pointopoint 10.0.0.33 User john now has escalated privileges with respect to the configuration of tun4, insofar as he can clear the IP address assigned simply by opening and closing the device. |