Glenn Faden's Blog

Regressions Shouldn't Happen

Guest Author

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

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

Join the discussion

Comments ( 2 )
  • Paul Spillers Saturday, July 21, 2007
    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.
  • Glenn Faden Sunday, July 22, 2007
    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.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.