Glenn Faden's Blog

  • January 26, 2009

Using IP Instances and Virtual NICs with Trusted Extensions

Guest Author

The OpenSolaris 2008.11 IPS packages are now organized in four respositories:

  • /release
  • /dev
  • /contrib
  • /pending

giving you the option to be a software pioneer. I used the /dev repository to update my Trusted Extensions laptop from the /release repository (running build 101) to build 105. In the Package Manager I selected Settings->Manage Repositories->Modify and changed the URL to http://pkg.opensolaris.org/dev. Then I selected Package->Update All, waited and rebooted. The new system came up running Trusted Extensions with only one hiccup: the Device Manager crashes when filling in its available device list; we're working on a fix.

My main reason for upgrading to this new build is that it includes new Virtual NIC (vnic) support  from the Crossbow project. This makes is easier to bring up both the wirelesss and wired NICs on my laptop, with the former  connected the public Internet, and the latter connected to Sun's Wide Area Network (SWAN). Naturally, I am using the trusted network features of Trusted Extensions to isolate these two networks. The wireless network is being used in my public zone and the wired network is used in the internal zone. Both networks are using DHCP, but each is independent. The public network is using NWAM, and is configured essentially the same way I have described in a previously entry.

The internal zone configuration is new. It takes advantage of the ability to create a vnic from the wired interface. Before doing so, I used the NWAM configuration menu in the GNOME panel to disable the wired interface. I first selected Always Use Wireless Network Interface (iwk0), and then selected the Edit Network Interface Priorities to ensure that Wireless (iwk0) was used. Since I wasn't sure that the NWAM GUI settings were persistent across reboots, I also edited the file /etc/nwam/llp, removing the entry for the wired interface.

Then I created a virtual instance of the wired interface.

# dladm create-vnic -l e1000g0 vpn0

for exclusive use within the internal zone. To change the zone's network configuration, I ran the following as root within the internal zone:

# sys-unconfig

which halted the zone. I used the zonecfg command to add the following to zone's existing configuration:

# zonecfg -z internal

zonecfg:internal> set ip-type=exclusive

zonecfg:internal> add net

zonecfg:internal:net> set physical=vpn0

zonecfg:internal:net > end

zonecfg:internal> exit

Since this zone will not be using the same DNS service as the global zone, it must have its own instance of the Name Service Cache Daemon, nscd. There is a global zone switch to run an instance of nscd in each zone. Although this can be set using the txzonemgr script, I wanted to continue sharing /etc/passwd and /etc/shadow, so I set the switch by hand as follows:

# touch /zone/internal/root/var/tsol/doors/nscd_per_label

This would normally be sufficient, except that I previously enabled another workaround which runs nscd with the privilege to communicate with lower-level DNS servers. So, it is also necessary to add the privilege net_mac_aware to the zone's default privilege set. This is done by adding the following line to /usr/lib/brand/labeled/config.xml:

<privilege set="default" name="net_mac_aware" />

The internal zone needs to be reconfigured as a DCHP client. This is done by copying the following into the file /zone/internal/root/etc/sysidcfg:

network_interface=PRIMARY {

All the zones must now explicitly use DNS, so I copied /etc/nswitch.dns to /etc/nwswitch.conf in each zone.

Since the internal zone runs its own network, it needs an eventhook script to setup /etc/resolv.conf and (optionally) the nis service. The one included in Darren Moffat's blog worked nicely. I copied it to /etc/dhcp, making sure it was executable. The final step was to assign the internal network template to the set of SWAN IP adresses. As a simple approximation, I just added the following to /etc/security/tsol/tnrhdb:

although the actual list of SWAN subnets is more restrictive (I'll fix this later). Then I crossed my fingers and rebooted the laptop. The two networks came up correctly. I brought up a Terminal in the internal zone, and verified that it was connected to SWAN. The only error I saw was that the nis client service in the internal zone was in the maintenace state. The log file complained that there was no binding directory for the nis service. I fixed that by typing:

# mkdir /var/yp/binding/it.sfbay.sun.com

# svcadm clear svc:/network/nis/client:default

Now I have two network infrastructures running on my laptop: an all-zones wireless interface for the public Internet, and a wired vnic interface for SWAN in the internal zone using nis. The only remaining problem is that the internal zone's network doesn't respond to ethernet hot-plug events. My workaround for this last minor problem is to restart the service in the internal zone by hand:

# svcadm restart svc:/network/physical:default

So now, I have a true mobile multilevel laptop which works anywhere on the Sun campus, that can be suspended and resumed, and automatically reconnects to both the Internet and SWAN networks.

Join the discussion

Comments ( 2 )
  • Chris Gerhard Tuesday, January 27, 2009

    Small typo. It should be:

    Settings->Manage Repositories->Modify

  • Stefan Hinker Thursday, October 15, 2009


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.