Thank you very much for the explanations. I understand what is being said. However, I still have not found an acceptable resolution to my problem. Partly because, I feel, I have not described my goal adequately. My goal:
For a labeled user on a Solaris 10 trusted extensions client to remotely login to a Solaris 10 trusted extensions server when using files as the name service. An example of this would be for a user in an unclassified labeled terminal window on the client to ssh into the equivalent labeled zone on the server. Usually there is no problem with this except when a user changes their password. Once a user changes their password on both systems they loss the ability to remotely login to each system until the zones are rebooted or the workaround is implemented. The zones can not be rebooted because they are actively being used. The workaround has security issues, as is stated in other posts to this thread, and is just that: a workaround. I do not believe I am asking for an enhancement or change especially because this functionality has worked in past Trusted Solaris operating systems. The following is an attempt to answer/explain ideas brought up in this thread concerning ldap and ipsec. As for ldap we have attempted to use it as our naming service however after more than a year of testing/researching we discovered many issues which would have to be resolved. We have not dismissed ldap as a solution however we are just testing if files as the name service would accomplish our goals. The following are some issues we discovered along the way. 1. LDAP could not import exec_attr entries. An IDR was released to fix this issue. Waiting on official patch which is supposed to be available in March 2009. Case 65867914 2. SMC incorrectly reads exec_attr and prof_attr containers in LDAP. Case 66059446 3. Projects/groups container conflict with ldap/SMC. Case number 65861615 4. We use hundreds of laptops and all need to have user accounts in sync with server. This meant all laptops must be master LDAP replicated servers. 5. No partial or customizable master replication between a classified server to an unclassified server. 6. A top secret user could not properly log into a secret system 7. Part of replication: home dirs not removed from replicated laptop 8. Could not properly uninstall DSEE/LDAP As for ipsec we have a case open (65754347) basically asking for labeled ipsec. It has been escalated and we have been told this is a huge undertaking and to implement it in U5 would take at least 11 bug fixes but less bug fixes in newer updates. Our problem with using newer updates is that U5 is going through Common Criteria at EAL4+ with RBAC, CAPP, and LSPP. This is a requirement from our customer. As such we can not just move to the newest update/version unless the new version completes the same Common Criteria evaluation. To give a little background my customer is converting from Trusted Solaris 8 to Solaris 10 with Trusted Extensions. Custom apps are created and used in the OS which are being ported to Solaris 10. We understand Solaris 10 is not Trusted Solaris 8 and things are fundamentally different in Solaris 10 with Trusted Extensions however we feel this functionality falls within reasonable expectations. Thank you very much for your help and time. Respectfully, Josh -- This message posted from opensolaris.org
