Regressions Shouldn't Happen

Unfortunately, they do. Before new features may be added to Solaris they must go through architectural review and exhaustive testing. Nevertheless, stuff happens. In Solaris 10 Update 4, and Nevada there are several new features that have had unexpected impact on Trusted Extensions functionality. Most of these get discovered and fixed quickly, but a few weren't understood and couldn't be fixed properly in time for the Update 4 release. So we have a few workarounds that will be required. I've been involved in the analysis of each of the these issues and thought it would be interesting to show why they were hard to find. In each case, the affected Trusted Extensions component had not changed since Update 3, so we weren't expecting breakage.

The first issue showed up in Trusted JDS authentication interfaces like role assumption. The Sparks Project enhanced the name service cache daemon (nscd), but changed the policy for accessing encrypted passwords. Previously, a process with all privileges but with a normal user ID, could call the PAM account management service which provides password aging and account locking. But the new architecture for nscd had the side-effect that root was now required. Although nscd has been fixed in Nevada to restore the previous behavior, there was insufficient time to backport this fix to Update 4. Therefore we integrated a workaround in the PAM stack for Trusted JDS to skip the failing check. A proper fix will be delivered in Update 5.

The next problem affected Trusted JDS workspace labeling. When a new label is applied to a workspace, the Trusted Stripe application uses the zone_enter() system call to initiate a session in the corresponding zone. Another project Duckhorn enhanced the resource management features of zones. One of these features, the capped-memory resource, imposed a new restriction on the zone_enter() syscall that prevented a process with a System V shared memory object from transitioning to a non-global zone. Meanwhile the GNOME toolkit was changed to use the X11 shared pixmap feature which affected the behavior of the Trusted Stripe process. As a result, the process was unable to initiate new sessions in labeled zones. Again, the root cause was discovered too late for a proper fix to be included in Update 4. Meanwhile, the workaround is to customize the TrustedExtensionsPolicy(4) file to disable the MIT-SHM X11 extension.

The third problem affects Trusted CDE in the specific laptop configuration that is described in the OpenSolaris Laptop Instructions. A change was made in Nevada to remove the installation question about enabling IPv6. Instead, the loopback interface is now plumbed with an IPv6 address, and services like the portmapper now support both IPv4 and IPv6 addresses. This configuration is partially incompatible with the use of the Virtual Network Interface, vni(7), as described in the laptop instructions. The Tooltalk RPC service which is used in Trusted CDE to initiate the Trusted Path does not get registered correctly with the portmapper when there are no physical interface plumbed. As a result the Trusted CDE session hangs. There are a variety of workarounds for this problem, and most people will never see it. In Update 4, don't enable IPv6 when asked, or don't use Trusted CDE until a physical interface has been plumbed. For Nevada, the workaround is described in step 4a of the revised laptop configuration procedures.

I'm frustrated by the above regressions, but I'm optimistic that things are getting better. The entire Trusted Extensions test suite has now been integrated into the Solaris Pre-Integration Test Suite (PIT).


Glen, I folloed the laptop instructions to a T using one of our BF II Models. Can you clarify the relationship between the physical interface (bge0) and the vni0 in thos instructions? I am trying to get rdesktop to run as a regular user. I can run it no problem as root but seems to be a routing issue or some type of netowrking issue when run as a user. Is it more of a permissions problem or do I need to declare the rdesktop to the public zone somehow? Any help would be great. Thanks. Paul

Posted by Paul Spillers on July 21, 2007 at 01:33 PM PDT #

It's not clear from your question if you are able to bring up applications in the public zone as a normal user, so I don't know where to begin. The vni0 interface only provides communication between labeled zones and the X11 server in the global zone. You must bring up a physical interface to run rdesktop. If you followed the directions, the public network template should be the default (for, after running inetmenu. So you should be able to ping the MS Windows server from the public zone. In general, you should post questions like this to the Security community in OpenSolaris.

Posted by Glenn Faden on July 22, 2007 at 05:27 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

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.


« June 2016