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