Saturday Aug 29, 2009

Using the Dev Repository with Trusted Extensions

Now that OpenSolaris 2009.06 has been released, the next major release is planned for 2010.02. You can get early access to it by pointing the Package Manager at the Development repository. Since the 2009.06 release, based on build 111, there have already been some major changes. The latest OpenSolaris build number in the Dev repository is 121, and updates occur about every two weeks. This release includes some changes to the labeled zone brand. A new meta-package called trusted-nonglobal specifies the minimal set of packages needed to run the Trusted Desktop in a labeled zone. This is now installed automatically via the txzonemgr. While this is referred to as a whole-root zone, it should not be confused with the way that term is used in Solaris 10. Previously, a whole-root zone contained a copy of all the packages that have been installed in the global zone. But a whole-root labeled zone is a minimized install. The list of packages in the labeled zone brand is enumerated in this manifest. Other differences in the configuration of labeled brand zones have been factored out of the template file and made part of the brand specification. This makes it easier to make future changes transparent to the administrator.

The latest version of GNOME is 2.26.2. This fixes some previous problems like the Trusted Stripe occasionally crashing. But there are still a few required workarounds. These should be fixed in the next major GNOME version, 2.28, which is scheduled for OpenSolaris build 124.

I've added a link to the Trusted Extensions page on OpenSolaris which describes how to install and configure Trusted Extensions using the latest version from the development repository.

Friday Jan 30, 2009

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!

Monday Jan 26, 2009

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 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/

# 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.

Sunday Jan 25, 2009

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.

Saturday Jan 17, 2009

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)

Friday Dec 26, 2008

Trusted Extensions Chapters in Two New Books

I've recently co-authored two chapters about Trusted Extensions. The first is a Case Study: Solaris Trusted Extensions in Trent Jaeger's new book Operating System Security. This book will be used in university classes, and addresses some of the trade offs made by security designers.

The second book Solaris Security Essentials, will soon be published by Sun Microsystems. It describes how to configure a Trusted Extensions system in Solaris 10. Various chapters in the book are currently available for review via the Safari Rough Cuts web site. Your feedback is welcome.

Obviously I'm pleased to have another opportunity to help new users get started with Trusted Extensions.

Device Allocation in OpenSolaris 2008.11

I've been having problems mounting removable media when Trusted Extensions is enabled in the latest OpenSolaris release, so I took a closer look at the shell script /etc/security/lib/disk_clean. This file handles mounting and unmounting of cdrom and rmdisk devices. There have been some subtle changes in the hal(5) framework which affect the script. Here is a copy of an updated version that works much better.

There are still a few other issues which I don't completely understand. The script invokes zenity(1) to pop up a few dialogs. With the latest version of GNOME (2.24) these dialogs are going behind the Device Manager, so you probably won't be aware of them unless you notice something flashing in the GNOME panel. The Device Manager will appear to hang until you respond to these dialogs (which you can't see). So move the Device Manager to one of the corners of your desktop before allocating a device, and look for these dialog windows when the program appears to hang. I tried fixing this with the System->Preferences->Windows menu, but that doesn't work for me.

Another problem is that all of the devices come up in the maintenance state when the system is booted, and must be reset via the Administration->Revoke item in the Device Manager. Devices are supposed to be reset to Available when the system is booted.

 I'm also seeing an occasional problem with cdrom0 being assigned to the wrong controller number in /etc/security/device_maps. If cdrom0 allocation isn't working for you, try this:

# eject cdrom

This comand will emit the full pathname for the cdrom device. It should match one of the devices in the Device Map, which you can view by picking the Administration->Properties item when cdrom0 is selected. If the controller number is wrong, either fix it in this dialog (which is tedious) or edit the underlying device_maps file.

One final issue is that the icons for the devices are missing from the repository, so the GUI has little blobs where the icons should appear. As a workaround, you can get the missing icons for this tar file, and extract it into /usr/share.

Saturday Dec 20, 2008

Suspend and Resume in OpenSolaris 2008.11

One of the significant new features in OpenSolaris 2008.11 is support for Suspend and Resume. Unfortunately, this feature doesn't show up in the GUIs when Trusted Extensions is enabled. This is similar to the problem with the nwam-manager discussed in the previous blog entry, but the workaround is a bit different.

The HAL daemon is responsible for granting permission to the user to suspend the system, and the daemon isn't be started properly when the TX user logs in. I worked around this be creating an executable shell script,


with the following two lines:


svcadm restart hal

The next time you login you should see the Suspend option in the Shut Down dialog and Power Management Preferences. Now you can suspend by closing the lid on your laptop. However, I found another issue with NWAM, so I have yet another workaround. When resuming after being suspended, NWAM doesn't automatically detect the your network status. I added the following line to the end of the shell script


(before the exit):

svcadm restart nwam

Now, I get connected to the new network when I resume my system.

Some Issues with Network Auto-Magic in OpenSolaris 2008.11

The instructions for Running Trusted Extensions in OpenSolaris 2008.11 don't include anything about configuring the network. I previously posted a blog entry Updated Laptop Configuration Instructions which is a bit out of date and confusing since Solaris 10, Nevada, and OpenSolaris are each a bit different. You can still follow these network instructions with OpenSolaris 2008.11, but use the new laptop instructions for the initial installation.

An improved NWAM version, 0.5, is included in this release, but there is an issue with launching the associated nwam-manager with Trusted Extensions. This program is supposed to be started via the launcher /etc/xdg/autostart/nwam-manager.desktop at login, but the TX session logic isn't doing this. As a workaround, add the following line to /usr/dt/config/Xinitrc.tjds, after the existing workaround to set the PATH environment at line 57:


You can still use the NWAM scripts included in this tar file, but you will need to add an entry to /etc/security/tsol/tnrhdb to assign a label to each OpenSolaris repository. Assuming your repository is,  you should do the following:

# tninfo -h

IP address=

Template = public

If the entry is not already admin_low, do this:

# tnctl -h

Then add the following line to the end of /etc/security/tsol/tnrhdb

The nwam-manager will be automatically started on the next login, and the Package Manager, and txzonemgr should both be able to install packages from the repositories via the global zone. However, labeled zones cannot currently install their own packages. If you need to install additional packages in your zones, there a few workarounds:

Edit the file /usr/lib/brand/labeled/pkgcreatezone and add the extra packages to $pkglist variable , following this convention:

pkglist="$pkglist SUNWnfsc SUNWatfs"

or you can run the pkg(1) command by hand in the global zone, specifying the zone's root path with the -R option set to something like /zone/public/root. Currently, there is no way to specify the destination directory pathname using the Package Manager GUI.

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  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.


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.


« July 2016