Tuesday Dec 09, 2008

Maintaining Zone Labels as ZFS Attributes

In Trusted Extensions each zone has a unique sensitivity label which is maintained as an entry in the tnzonecfg database. Since ZFS is used to instantiate zones, each zone also has a unique dataset. When the zone is started by  zoneadm, its dataset is mounted according to the pathname assigned to it when the zone was created.  This mount point is maintained as a ZFS attribute of the dataset. The zone's label is associated with its mount point label, which is determined by comparing its pathname to the root pathname of the currently active zones. So there is no automatic facility to determine the label of the zone's dataset until the zone's attributes are loaded into the kernel by zoneadm.

However, we can implement a means to display the label, even when the zone is not active, by assigning the label value as a ZFS attribute. The convention for naming such attributes is to use a colon in its name, so I've named the attribute mls:label. In order to automatically assign labels to these datasets, you need to modify the txzonemgr shell script. There are three functions in this shell script, install(), clone(), and copy() where zone datasets are created. In each of these functions I added the following one line at the end of the function, after the corresponding zoneadm operation completes:

 /usr/sbin/zfs set mls:label="$curlabel" \\ $ZDSET/$zonename

The value $curlabel contains the string that is assigned by the menu item Select Label , so it is necessary to perform that step before selecting Install, Clone, or Copy.

The value $ZDSET is automatically determined, and $zonename is set when you name your zone. If you are running OpenSolaris, or Solaris 10 update 6 (or newer) with ZFS as your root filesystem, then $ZDSET is rpool/zones. Otherwise it is simply zone.

Once your datasets are created, you can view all their labels and their corresponding mount points with this command:

zfs list -ro mountpoint,mls:label $ZDSET

In the above command, please substitute the appropriate value for $ZDSET. The -ro parameter specifies a recursive option, not read-only.

The output should look like this:


/zone                ADMIN_HIGH

/zone/public         PUBLIC


/zone/needtoknow     CONFIDENTIAL : NEED TO KNOW

Note that these attributes can only be changed by a root process in the global zone, and are inaccessible from within the labeled zones.

Friday Nov 21, 2008

Trusted Extensions in OpenSolaris 2008.11

I've posted a few entries about running Trusted Extensions using OpenSolaris 2008.05. Now that OpenSolaris 2008.11 is about to be released, the instructions have been updated again, and are now available here. The Package Manager GUI now has built-in support for Trusted Extensions which simplifies the installation. The new ISO image should be ready in a week or two.

Sunday Sep 21, 2008

Updates on Running Virtualized Guests in Labeled Zones

Last April I posted some procedures for running Vista in labeled zones using VirtualBox. When VirtualBox 2.0 was released a few weeks ago, I decided to try out some of the new features. I think the coolest one is the way the seamless mode works with Trusted Extensions. In seamless mode, all the Vista windows, including the Task Bar are rendered in a single fullscreen X11 window using the Shape extension. Previously I've seen this extension used for non-rectangular windows like round clocks. But, in this case, the all the Vista windows are in a single plane, with holes cut our where the Vista desktop would normally appear. So the GNOME windows, including the nautilus desktop are visible through these holes. Furthermore, the pointer focus passes through these holes to the next window, so the Trusted Stripe accurately displays the label of the pointer as it is moved across Vista windows and the GNOME windows behind the holes.

In my previous blog entry, I mentioned that it was necessary to start an instance of VirtualBox in the global zone since the vboxdrv driver couldn't  be loaded from a non-global zone. I've come up with a simple alternative, although it isn't officially supported. Instead of starting a new instance of VirtualBox in the global zone, it is sufficient to keep the device open using a command like the following:

tail -f /dev/vboxdrv >/dev/null 2>&1 &

For expediency, I added this single line to the end of the start method in the zones SMF service, /lib/svc/method/svc-zones. While this actually works, we need to figure out a more supportable technique.

Another issue that I raised in the previous blog entry was that the Vista guest needs to communicate directly with the DNS server, so it must be assigned a single-level network template with the same label as the zone in which the guest is running. However, this causes problems with applications in other zones that rely on the Name Server Cache Daemon, nscd(1M), which proxies DNS requests from labeled zones into the global zone. An interesting workaround is to allow nscd in the global zone to send requests to unlabeled servers even if their labels don't match. This can be specified by wrapping the start method for nscd, in the file /lib/svc/method/svc-nscd as follows:

/usr/bin/ppriv -M -e /usr/sbin/nscd < /dev/null > /dev/msglog 2>&1 &

The -M option of ppriv(1) enables the special process attribute NET_MAC_AWARE. The combination of this process attribute, the privilege, priv_net_mac_aware, and the assignment of a matching trusted network template entry in tnrhdb, allows the global zone instance of nscd to proxy DNS requests from all zones, and concurrently allows the Vista guest to communicate directly with the remote DNS server.

Using these techniques, I can now run two instances of Vista in separate VirtualBoxes, each in their own labeled zones. The first instance, running in the public zone, uses the public network. The other Vista instance, running in the internal zone, uses a commercial Windows VPN application, so only its VPN endpoint requires a matching label.

To save time, disk space and virtual memory, I created a ZFS dataset for the public instance of Vista, and created a ZFS snapshot after completing the Vista installation. I then cloned the snapshot for use in the internal zone. Normally this would cause a problem with VirtualBox which requires that each Virtual Disk Image (.vdi) has a unique UUID. However, since the two instances of VirtualBox are completely isolated from each other in uniquely labeled zones, they can share the same UUID.

On the other hand, to comply with the Microsoft license, each instance of Vista requires a unique activation key.

Demonstrating Process and File Labeling

Since I do a lot of Trusted Extensions demonstrations, I'm often asked about process and file labeling. Both process and file labels are implicitly determined from zone and network labels. I've written two shell scripts which display these concepts using the zenity(1) GUI.

Here is the first script, getprocs:


ps -fe -o comm -o user -o pid | \\

while read command user pid
        label=`plabel $pid 2>/dev/null`
        if [ $? = 0 ]; then
                echo $command;
                echo $pid
                echo $user
                echo $label
done | zenity --list \\
        --title=" Process Labels" \\
        --height=700 \\
        --width=650 \\
        --column="Process Name" \\
        --column="ID" \\
        --column="User" \\
        --column="Sensitivity Label"

The output of the script looks like this:

If you run this in the global zone, as root, you will see all processes and can sort the output based on the table columns. When run in a labeled zone, only processes with the current zone label are shown. I also use this script to demonstrate that by removing proc_info from my default privilege I can only see my own processes. The privilege setting in my /etc/user_attr file looks like this:


The other script, getmounts, displays the label of the currently mounted filesystems.


/usr/sbin/mount -p | cut -d " " -f3-4 | \\

while read mntpnt fstype
    label=`getlabel $mntpnt 2>/dev/null`
    if [ $? = 0 ]; then
        echo $mntpnt
        echo $fstype
         echo $label | cut -d : -f 2-99
done | zenity --list \\
    --title="File System Labels" \\
    --height=700 \\
    --width=750 \\
    --column="Directory" \\
    --column="Type" \\
    --column="Sensitivity Label"

When run as root in the global zone, everything is displayed except NFS mounts to the labeled zones. When run in a labeled zone, only the labels of the zone's filesystems, and those shared filesystems from the global zone and from lower-level zones or NFS servers are shown.

The output of this script looks like this:

Towards Running Trusted Extensions with OpenSolaris 2008.11

In July I posted a set of procedures for getting Trusted Extensions working in OpenSolaris 2008.05, based on the build 93 repository. Dr. Christoph Schuba has updated those procedures to work with the latest repository based on build 97. By the time OpenSolaris 2008.11 is released we hope to have integrated fixes for all of the current workarounds. Meanwhile, I've verified the updated procedures in Christoph's blog, so you should use them until the formal release of OpenSolaris 2008.11.

Saturday Jul 19, 2008

Running Trusted Extensions with opensolaris.2008.05

When the LiveCD for opensolaris was released last May there was no support for Trusted Extensions. We've made some progress, and I'm happy to report that I am posting this blog in a labeled zone running opensolaris. There are workarounds for the zone installation, X11 remote connections, and desktop login, which are all temporary until the underlying bugs are fixed.

This week the repository at http://pkg.opensolaris.org  was updated to contain packages based on Nevada build 93. This is being referred to as opensolaris.2008.11 since we are targeting the next release in November. There are posted directions for upgrading the pkg software for this build, and then doing a complete pkg image-update. I tried this, but I was not able to install any zones with the new pkg software. So I came up with my own procedure. Instead of doing a complete pkg image-update, start by installing the 2008.05 LiveCD.

Make sure that the entry for root in /etc/user_attr does NOT specify type=role.

Then do the following:

# pkg refresh --full
# pkg install SUNWts@0.5.11,5.11-0.93
# pkg install SUNWtsg SUNWxorg-tsol-module

# pkg install SUNWtgnome–tstripe SUNWtgnome–tsoljdsselmgr SUNWtgnome–tsoljdslabel SUNWtgnome–tsoljdsdevmgr SUNWtgnome–xagent
# pkg install SUNWgnome-file-mgr@0.5.11-0.93
# pkg install SUNWgnome-wm@0.5.11-0.93

This will get you the subset of updated and new packages required to run Trusted Extensions. Next you should download and install a set of files which specify a new labeled zone brand. Extract the tar file into /usr/lib/brand. The labeled brand needs to be specified in the default template, so edit the file /etc/zones/SUNWtsoldef.xml to specify that brand:

 <zone name="tsoldef" zonepath="" autoboot="true" brand="labeled" >

It is necessary to enable TCP connections to the X11 server. This must be specified for gdm and well as Xorg. To configure the gdm property, run the gdmsetup GUI. Select the Security tab, and uncheck the setting for Deny TCP connection to Xserver. Then run the following command:

# svccfg -s x11-server setprop options/tcp_listen=true 

There is another problem with argument passing between gdm and tsoljdslabel, which requires some fiddling. First do the following:

# cd /usr/bin

# mv tsoljdslabel tsoljdslabel.orig

Next create an executable shell script named tsoljdslabel with the following contents:

/usr/bin/tsoljdslabel.orig /etc/dt/config/Xinitrc.tjds

Now do the following:

# mkdir -p /etc/dt/config

# cp /usr/dt/config/Xinitrc.tjds /etc/dt/config

There is another problem where  Xlib misinterprets DISPLAY variables of the form hostname:0. Also, the path for users and roles is too restrictive. The workaround is to edit the file /etc/dt/config/Xinitrc.tjds as follows:

export DISPLAY=
export PATH=/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/X11/bin:/usr/dt/bin:/usr/sfw/bin
echo 'Starting gnome-session'
exec $command

The last workaround is to move the top panel to the bottom to prevent it from being obscured by the screenstripe. To do this, mouse over an empty area in the top panel, and use the right mouse button to bring up the Properties dialog. Change the orientation from Top to Bottom.

To enable Trusted Extensions, do the following:

# svccfg import /var/svc/manifest/system/labeld.xml

# svcadm enable -s labeld

# reboot

If you were very careful, you should be able to login as root. Do not specify a session type since you can only run a Trusted JDS session. Now create your zones using the txzonemgr. Since all filesystems are using zfs, you should not create a zpool for zones. A dataset for each zone will be created automatically.

Currently the Solaris Management Console is not included in the repository, so you will need to create users and roles with other commands. Once you get this working, you may want to install the NWAM configuration files I discussed in the previous posting, Updated Laptop Configuration Instructions.

Monday Jul 07, 2008

Updated Laptop Configuration Instructions

The Laptop Instructions for Trusted Extensions have been revised to focus on the latest updates of Solaris 10 and Nevada. In Solaris 10 update 5 and Nevada, there is no longer a separate installation step, since Trusted Extensions is enabled as an SMF service. However, there are still some significant differences with respect to configuring a laptop using DHCP. The new instructions take advantage of the Network Auto-Magic project (NWAM). Included in the instructions is a tarball of shell scripts for specifying label-related behavior of the dynamically assigned address. These scripts conditionally assign the appropriate default network template, public or internal, based on the domain name returned by the DHCP server. For example, in my case, if the domain is sun.com, then the default template is internal. You can edit the INTERNAL_DOMAIN variable in the check-configuration file to specify your own internal domain.

These NWAM scripts also manage an additional logical interface using the physical interface that is currently in use. It is only visible in the global zone to support NFS file sharing, and is therefore called mynfs. To avoid conflicts with network assigned addressses, I used a private network address of for mynfs, and use the all-zones DHCP assigned address to route NFS requests from labeled zones into the global zone. 

I prefer using an NFS server on my laptop, instead of relying on the cross-zone LOFS mounts of /export/home that are automatically created when zones are booted. The LOFS mechanism occasionally get out of sync with the automount daemon depending on the order in which the zones are booted. Furthermore, the NFS mechanism is more configurable and demonstrates some commonly misunderstood features of Trusted Extensions.

Instead of separate instances of /etc/dfs/dfstab for each zone, I am using the sharemgr tool. I created a sharemgr group for each zone, e.g.

# sharemgr create public

# sharemgr add /zone/public/root/export/home public

The actual sharing occurs when the zone is booted. There are two shell scripts in /usr/lib/zones that are called when zones are either booted or halted. I modified zoneshare to call

sharemgr enable $zonename

and similarly, I modified zoneunshare to call

sharemgr disable $zonename

Then I modified the file /etc/auto_home_public in each of the higher-level zones, as follows:

\*       mynfs:/zone/public/root/export/home/&

This works well for me unless my network connection changes while the NFS mount is active. That's because the underlying logical interface for mynfs is unplumbed and moved to a new logical interface when I switch between wired to wireless.

Monday Jun 23, 2008

Common Criteria Certification

The Solaris 10 11/06 release of Trusted Extensions has finally received its Common Criteria certification. Like it's predecessor, Trusted Solaris 8, the assurance rating is EAL4+ in conformance with the Controlled Access, Role-Based Access, and Label Security Protection Profiles. The evaluation was performed by CGI Information Systems & Management Consultants Inc, and is listed on the Canadian Common Criteria list of certified products. You can also view the certificate and the Security Target on this page. The evaluated configuration, described in Section 2.3, page 8,  is the most comprehensive for any product at this level. Among the Solaris features included are both the JDS (GNOME) and CDE desktops, the Solaris Management Console, both SPARC, x64 and x86 hardware, UFS, ZFS and NFS, and a distributed configurations administered using LDAP.

The currently shipping release, Solaris 10 5/08, will go through the rating maintenance process so that the certification can be applied to the latest software and hardware.

Friday Apr 18, 2008

Fully Open-Sourced Multilevel Desktop

It's taken a while to get all the legalities worked out, but I'm pleased to announce that all of the source code that you need to build the Trusted Java Desktop System (aka TJDS), is now fully open and browsable in the OpenSolaris source browser. Most of the code has been open for for two years, and was written before marketing picked the name Trusted Extensions. So all of these component have names containing the abbreviation tsol, which originally stood for Trusted Solaris. The newly available source includes:

libgnometsol - functions for label selection and role assumption

tsoljds-tstripe - trusted stripe and trusted path menus

tsoljdsdevmgr - device allocation GUI

tosljdslabel - GUIs for initiating multilevel and single level sessions

tsoljdsselmgr - trusted selection manager

These components  depend on two Trusted Extensions libraries:

libtsol - functions for label translation and comparison

libXtsol - functions for managing labels in the X11 server

While all of these components are open, they are covered by different license agreements, depending on their consolidation. The GNOME-related components are covered by GNU General Public License version 2. The library libtsol is covered by the Common Development and Distribution License , and libXtsol is covered by the X.Org license.

Monday Apr 07, 2008

Virtualized Instances of Vista in Labeled Zones

You may have read Sun's announcement about acquiring innotek, and the VirtualBox software. VirtualBox runs on a variety of operating systems including OpenSolaris, and supports a variety of guest operating systems, such as Microsoft Vista. Since VirtualBox is a user application, it can also be run in Solaris zones. Getting Vista to run in labeled zone requires a few extra configuration steps, which are described below.

VirtualBox can be downloaded from the Sun Download Center and installed in the global zone. When VirtualBox is started in the global zone a device driver is loaded which is accessed through the pathname /dev/vboxdrv. To access this device from a zone, modify the zone's configuration using the following zonecfg commands:

add device

set match="/dev/vboxdrv"


Since zones cannot load kernel modules directly, you must have an instance of VirtualBox running in the global zone to load the driver. I suppose you could alternatively load the driver via modload, but I haven't tried that yet.

In addition, the zone needs to be running the OpenGL service. To enable this service, run the following command in the zone:

 svcadm enable ogl-select

VirtualBox acts as a network proxy between the host and guest operating systems. This works fine in the global zone, but presents a few issues when running in a labeled zone. The DNS service that VirtualBox provides to the guest OS does not go through the name service switch. Therefore each zone must have its own DNS configuration, and a remote DNS server whose label matches that of the zone. To set this up you should halt your zones and select Configure per-zone name services from the top level menu of txzonemgr. Since your labeled zones will no longer be able to access any of your global zone databases, you should copy the /etc/hosts, /etc/passwd, /etc/shadow and /etc/user_attr files from the global zone into the corresponding /etc directory for each of your zones. You will also need a customized /etc/resolv.conf file for each zone to specify the appropriate DNS server for each label.

If you are using DHCP, you will be limited to name resolution in a single zone. You can rely on the nwam service (which is enabled by default) to set up your networking in the global zone. To make the network available to a labeled zone, you should share the configured network with all-zones (via txzonemgr or ifconfig) and assign the approriate single-level remote host template to the DNS server specified in /etc/resolv.conf. Then copy the resolv.conf file into the appropriate zone.

Once you have set up your zones and networking, you can install Vista, or your another OS as the guest OS. After the guest OS is installed, you should verify that the guest OS can access the Internet. If so, you should download and install the guest additions ISO image. This will allow you to cut and paste between Vista and Solaris applications in the same zone. It also provides dynamic resizing of the guest OS window, and smooth mouse transitions between the host and guest windows.

Friday Mar 14, 2008

Flexible Mandatory Access Control

A new project, FMAC,  has been initiated to add a security server based on the Flux Advanced Security Kernel (Flask) architecture to OpenSolaris. A press release has been issued announcing the joint effort between Sun and the National Security Agency. Several bloggers ( bvassjimlaurentbarton808 ) have already posted comments and there seems to be significant interest in the community.

However, I think that it's prudent to look closely at these announcements rather that making assumptions about what is being proposed. Flask provides significant opportunities to customize the policies enforced in the kernel and in user space, but it's flexibility also poses configuration challenges. One of the things that makes Solaris popular is that it provides stable, backward-compatible binary and procedural interfaces. This constraint applies to all new projects including FMAC. Core Solaris features like Role-Based Access Control, Process Rights Management, and Multilevel Security must co-exist with new polices based on Flask. For this reason, the initial emphasis of the FMAC project should be to supplement these existing access control policies where they are deficient.

For example, it is difficult to restrict untrusted applications which run in a user context from modifying the files owned by that user. The related Fine-Grained Access Policy project addresses this issue by handling exceptions to access control denials that occur due to lack of privilege. In contrast, FMAC plans to pass all access control decisions through an extensible policy server which will make access decisions based on the policy defined for the security contexts of the subjects and objects.

Flask has been implemented in SELinux, SEBSD, and SEDarwin, but the level of complexity has caused many end-users to disable it. We don't want this to happen in OpenSolaris, so we will need to balance improvements in the safety of running untrusted applications while making it transparent to normal users.

Type Enforcement will be the key technology upon which such flexible policies will be based. Unlike MLS sensitivity labels, there is no inherent hierarchy associated with Types, and it is common for the Type to change when a parent executes a new application. MLS labels are static, and are associated with labeled zones in OpenSolaris. Types are also quite different from the authorizations and process rights (privileges) upon which Solaris RBAC is based. Type Enforcement rules can be used to define more flexible policies than these existing mechanisms.

The challenge facing this project will be to add value to Solaris without compromising its existing strengths. For example, the MLS policy in use today is completely invisible to applications because all conflicting resources are polyinstantiated using zones. My preference is that the FMAC project should focus on defining new policies based on Type Enforcement, while preserving the existing policies for Discretionary Access, Multilevel Security, user authorizations, and process privileges that we have today.


Sunday Jan 06, 2008

Using Xvnc for Remote MLS Sessions

This is an update to my posting Remote Multilevel Desktop Sessions from last August. At that time I suggested using a combination of Xvfb(1) and vino-session (x86) or x0vncserver (SPARC) to get both the features of vnc and the Trusted Extensions X protocol extension to work together. However, starting in SXDE 1/08 and the upcoming Solaris 10 update 5 beta, we now deliver a version of Xvnc which supports both protocols in a single binary based on the current version of Xorg. Since it uses a virtual framebuffer, it should work with either architecture.

 The easiest way to take advantage of this on a headless server running Trusted Extensions is customize the file /etc/dt/config/Xservers. Simply comment out the default line and add this new one:

#   :0  Local local_uid@console root /usr/X11/bin/Xserver :0 -nobanner
  :0   Local local_uid@none root /usr/X11/bin/Xvnc :0 -nobanner -AlwaysShared -SecurityTypes None -geometry 1024x768x24 -depth 24

Note that I have disabled password authentication because I am using this machine for software development. If you need more restrictive access, remove the -SecurityTypes option.

To make a remote connection (using a vnc client) your client machine should be assigned the admin_low template in server's tnrhdb file.

Monday Dec 31, 2007

Multilevel Mail Revisited

In my posting last February, Prototyping Multilevel Mail, I discussed some techniques for  implementing an email service to support labeled zones. It turns out that a company called BlueSpace Software has done just that. They have a very cool demo showing their label-aware email client running under Trusted Extensions using the Trusted Java Desktop System. The product is called BlueSpaced TransMail Trusted Edition. Here is a quote from their web page:

TransMail Trusted Edition tightly integrates with Solaris 10 Trusted Extentions to ensure appropriate content management between the different security zones, including data labelling so that the interface operates mutliple network sessions simultanteously. 

I haven't had a chance to try it out, but I'm looking forward to doing so when it is available. 

Friday Dec 28, 2007

Regressions Get Fixed

Some months ago I regretfully posted an entry entitled Regressions Shouldn't Happen.

All of the bugs referenced in that posting have been fixed and patches have been released. In addition, a large number of additional bugs have been found and fixed. The current list of required patches is available here, and on the OpenSolaris Trusted Extensions page.  If you are installing from the latest OpenSolaris build, or the upcoming Solaris 10 update 5 beta release, these fixes have already been incorporated into those distributions.

On a related issue, we have completed the integration of all of the "Extra Value" packages for Trusted Extensions into the standard Solaris and OpenSolaris metaclusters. I first wrote about this in Automatic Installation of Trusted Extensions.  Starting with the Solaris 10 update 5 beta release, there is no longer any separate installation step for Trusted Extensions software. To enable multilevel security you will need to enter the following SMF service:

svcadm enable -s labeld

Thursday Dec 27, 2007

Sun Tech Days in Tokyo

I haven't posted to my blog in a couple of months, so my New Year's resolution is to post more often.

Last month I took a working vacation through Japan, which started and finished in Tokyo. Here's what a working vacation looks like:


I was there to participate in the local Sun Tech Days conference.  Here are the slides for two of my presentations: New Security Features in Solaris 10 and OpenSolaris, and Let SMF Deal With That: An Introduction to SMF.  I visited some customer sites, so I got a Japanese business card for introductions (with two hands, as is the custom):

Japanese Card 

I was also interviewed for a local publication; here is partial transcript. I pasted one of these answers into Google's translation service, and got back this:

Q: How is the reputation of Solaris OS?

A: Until see the introduction of the Solaris to the high expectations
and satisfaction. However, the OS is secure because it was, all issues
to be settled is not. It is actually the most difficult, as the
organization's security policy planners think. Sun has experienced so
many engineers, we encourage you want to ask.

Which is (hopefully) not exactly what I actually said. Anyway, it was a great trip, and I'm looking forward to my next Sun Tech Days trip to St. Petersburg, Russia.


This blog explores some of the security features of Oracle Solaris. In particular, topics such as Role-Based Access Control and Labeled Security are my special interests.


« February 2015