If you prefer not to have UML use uml_net (which is somewhat insecure), with UML 2.4.17-11, you can set up a TUN/TAP device beforehand. The setup needs to be done as root, but once that's done, there is no need for root assistance. Setting up the device is done as follows:

        * Create the device with tunctl (available from the UML utilities tarball)

              host# tunctl -u uid 

          where uid is the user id or username that UML will be run as. This will tell you what device was created.
        * Configure the device IP (change IP addresses and device name to suit)

              host# ifconfig tap0 192.168.0.254 up 

        * Set up routing and arping if desired - this is my recipe, there are other ways of doing the same thing

              host# bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

              host# route add -host 192.168.0.253 dev tap0

              host# bash -c 'echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp'

              host# arp -Ds 192.168.0.253 eth0 pub 

          Note that this must be done every time the host boots - this configuration is not stored across host reboots. So, it's probably a good idea to stick it in an rc file. An even better idea would be a little utility which reads the information from a config file and sets up devices at boot time.
        * Rather than using up two IPs and ARPing for one of them, you can also provide direct access to your LAN by the UML by using a bridge.

              host# brctl addbr br0 

              host# ifconfig eth0 0.0.0.0 promisc up 

              host# ifconfig tap0 0.0.0.0 promisc up 

              host# ifconfig br0 192.168.0.1 netmask 255.255.255.0 up 

              host# brctl stp br0 off 

              host# brctl setfd br0 1 

              host# brctl sethello br0 1 

              host# brctl addif br0 eth0 

              host# brctl addif br0 tap0 

          Note that 'br0' should be setup using ifconfig with the existing IP address of eth0, as eth0 no longer has its own IP.
        *

          Also, the /dev/net/tun device must be writable by the user running UML in order for the UML to use the device that's been configured for it. The simplest thing to do is

              host# chmod 666 /dev/net/tun 

          Making it world-writeable looks bad, but it seems not to be exploitable as a security hole. However, it does allow anyone to create useless tap devices (useless because they can't configure them), which is a DOS attack. A somewhat more secure alternative would to be to create a group containing all the users who have preconfigured tap devices and chgrp /dev/net/tun to that group with mode 664 or 660.
        * Once the device is set up, run UML with

              eth0=tuntap,devicename 

          i.e.

              eth0=tuntap,tap0 

          on the command line (or do it with the mconsole config command).
        * Bring the eth device up in UML and you're in business.

    If you don't want that tap device any more, you can make it non-persistent with

        host# tunctl -d tap device 

    Finally, tunctl has a -b (for brief mode) switch which causes it to output only the name of the tap device it created. This makes it suitable for capture by a script:

        host# TAP=`tunctl -u 1000 -b`