SuperHappyDevHouse Event at Sun
Sun is hosting an Open House at its Executive Briefing Center on Saturday, January 31, for a local technical community called SuperHappyDevHouse. I have set up a demonstration system with 50 zones which is wide open for exploitation. The root password is posted, and remote access via vncviewer or telnet is unrestricted. This is a great opportunity to own your own zone, do whatever you want to it, and not get in trouble. All of the zones are cloned from a ZFS snapshot, so I can quickly restore them if they are destroyed. They are using the new Virtual NIC (vnic) support that I discussed in my previous blog entry. So each zone gets its IP addresss from the same WiFi access point as our visitors. The ssid is ZONES.
This is all running on a single UltraSPARC T2 processor, with 8 cores and 64 hardware threads. It is running Solaris Nevada build 105. A corresponding x86/x64 version of OpenSolaris is available here.
Here is a very brief overview of the zone configuration, access instructions, and a list of activities to try. Have fun!
Posted at 08:59PM Jan 30, 2009 by gfaden in Sun | Comments[0]
Using IP Instances and Virtual NICs with Trusted Extensions
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:
system_locale=C
terminal=vt100
network_interface=PRIMARY {
dhcp
protocol_ipv6=no
}
nfs4_domain=dynamic
security_policy=NONE
name_service=DNS
timezone=US/Pacific
service_profile=limited_net
timeserver=localhost
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:
129.0.0.0:internal
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.
Posted at 07:12PM Jan 26, 2009 by gfaden in Sun | Comments[2]
Improving X11 Performance and Security
The X11 server in OpenSolaris is configured using the limited_net service profile (Secure by Default) so that it does not listen for TCP connections. Instead, it relies on the local transport, UNIX domain sockets. When Trusted Extensions is enabled via the SMF labeld service, this restriction is relaxed to allow some TCP connections. This was necessary because UNIX domain sockets could not be used for the cross-zone access required by X11 clients running in labeled zones. To minimize the risk, the X11 server rejects connection from untrusted X11 clients. However, this solution was not ideal because TCP connections are slower than UNIX domain and require network connectivity between labeled zone clients and the global zone X11 server.
Starting with OpenSolaris 2008.11, UNIX domain socket can now be used by labeled zone X11 clients, but the configuration does not yet work be default. The workaround is fairly simple, and actually reverses a previous workaround that I described last July. Here are the steps:
# mkdir -p /etc/dt/config
# cp /usr/dt/config/Xinitrc.tjds /etc/dt/config
In the new Xinitrc.tjds file, change the setting for the DISPLAY variable and add the following mount command
# Workaround Xconnecion problem
export DISPLAY=unix:0
mount -F lofs /tmp/.X11-unix /var/tsol/doors/.X11-unix
Then you can disable the TCP listener in the X11 server as follows:
# svccfg -s x11-server setprop options/tcp_listen=false
These changes will take effect on the next login. This configuration makes it easier to use exclusive IP stack instances, since the X11 clients no longer need any access to the global zone's network. I'll explore that more fully in my next blog entry.
Posted at 09:03PM Jan 25, 2009 by gfaden in Sun | Comments[0]
3D Accelerated Virtualized World Tours
The latest VirtualBox 2.1 release includes a new experimental* high performance XGL driver for Windows guests. This makes it possible to run 3D applications like Google Earth in virtualized environments with excellent performance. I've previously blogged about running VirtualBox guests in labeled zones. But the new 3D capability is so amazing that you have to see it to believe it. Now I've made my first YouTube video, showing the system performance on my Toshiba M9 with 4GB of RAM. An instance of VirtualBox is running in each labeled zone, and an instance of Microsoft Vista is running in each VirtualBox. Each Vista instance is running Google Earth, at high speed using the virtual XGL driver included in the VirtualBox Guest Additions.
I also uploaded a QuickTime version of this video to Sun's MediaCast web site which provides higher resolution than YouTube.
Since this is a security blog, it is important to mention that the network isolation provided by Trusted Extensions extends only as far as the Vista guests. The PUBLIC instance is connected to the public Internet, and the CONFIDENTIAL : INTERNAL USE ONLY instance in connected to Sun's Wide Area Network (SWAN) via the Cisco 3000 VPN. Although the remote VPN endpoint has been labeled CONFIDENTIAL : INTERNAL USE ONLY, neither the Cisco VPN server nor SWAN are label-aware, so the network isolation enforced by Trusted Extensions doesn't extend outside of SWAN. That's why the internal zone instance of Google Earth can connect to the PUBLIC Google servers. The Windows VPN hides this traffic from the Solaris kernel. In a classified environment, this would not be permitted.
For those trying this at home, I pulled out all the stops the get the best performance. I used UNIX domain sockets instead of TCP for X11, and I ran the demo several times to get the images into the cache. Otherwise this ran on the official releases of OpenSolaris 2008.11 and VirtualBox 2.1.
* see user manual, chapter 4.8, Hardware 3D acceleration (OpenGL), page 66)
Posted at 10:30AM Jan 17, 2009 by gfaden in Sun | Comments[2]