Well.. the common sense when the user wants to be able to change IP addresses
is to use a subnet TAP device, not a point-to-point one (which by the way makes
little sense for TAP... why use a ethernet model for point-to-point?).
TAP is intended when you need ethernet for one reason or another. In the
UML case mostly when using bridging to seemlessly give the UML direct ethernet
access to the local ethernet network (or a virtual LAN), It is not really
intended for point-to-point communications like host<->UML. For such
communications PPP is probably the best choice (SLIP is not the best choice
because it is limited to IP only).
Any ETHERTAP/TAP/TUN support in UML should be made generic, not assuming
anything except for the transport model. These are very handy when doing
advanced networking, and if you make assumptions about how they are used in
communication with UML then the applications of UML will be limited. The
UML should be able to see these as a virtual NIC using ethernet frames (higher
level frames in case of TUN), nothing more. What is on the other end of the
"NIC cable" is the host responsibility.
Securing ETHERTAP/TAP/TUN can be done with preconfiguring and firewalling on
the host if required. See also below for reasoning why this is the proper place
for securing these transports..
If you want a "secure" setup where the UML user cannot mess with things,
automatic routing and everything else then use PPP over a PTY. There are
already well established frameworks for how to set up and control
PPP connectivity in a secure manner on both ends (i.e. both host and UML). What
you need to support in UML to be able to do this is some whay to specify a
virtual serial device that will allocate a host PTY and launch "pppd" or
another kernel command-line specified program there. In the UML you then
configure this more or less as a normal dial-out connection.
Any attempts to try to build new "secure" methods will most likely fail.
Requiring custom SUID helpers is not a very wise thing as writing a secure
SUID helper is far from easy, and most security minded administrators are
VERY reluctant about installing a SUID helper simply because they know that
99% of all "SUID helpers" are broken and can be abused to give full superuser
access to the users who can execute them.. (which in the case of UML is any
hacker within the UML who knows it is a UML.. not only the user starting the
Note: Thinking that your "source code split" between user-mode and kernel-mode
is a security measure is only giving a false sense of security. From a security
point of view you must assume that the whole UML has the same privilegies as
the user starting the UML. If a UML gets hacked it is fully possible to break
out of the UML and execute things on the host. Sure, a script-kiddie won't know
how to yet for a while, but for a serious Linux hacker knowing about UML it is
about a couple of minutes job.
If you want a very simple networking setup with no real care of host security,
then use ETHERTAP/TAP/TUN with a suid helper that opens the device and gives it
to UML, sets up the host interface and proxy-arp.
If you want a reasonably secure but still very simple setup then require that
the user can open the ETHERTAP/TAP/TUN device, and have the host adminstrator
pre-configure host interface(s) and proxy-arp/bridging.
If you want a more secure setup, then use PPP, and "dial out" from UML to the
host, and hint to the host administrator that firewalling might be a good
Jeff Dike wrote:
> johan.verrept@... said:
> > kewl. Not specifying the uml-side address also means you won't have
> > any problems trying to prevent multiple ipaddresses being assigned to
> > your ethertap device.
> There's just one slight problem with this. If the IP address is changed, I
> don't see a way for the driver to be told so that it can changing the arping
> or routing on the host.
> That's not the common case, so I'm not terribly concerned about it.