Mike Lewis wrote: >One thing I was a bit confused by were the commands I could issue to the >zones - start, restart, make_ready. I am used to the zoneadm arguments of >boot, reboot, halt, etc, and I thought these commands should be >consistent. > >
You're probably right. I was trying to match these to the corresponding CDE actions. But they probably have the wrong names, too. :-( >One thing I would like is a zone manager that would edit the tnrhdb and >tnzonecfg files when a new zone is created/cloned. So, I could clone a >SECRET A zone to SECRET B and have the new zone be ready to boot at the >end of the cloning, already configured to be SECRET B and have the cipso >entry in the tnrhdb file to allow it to communicate with the rest of the >system (although I can see a security need for having a human manually >editing those critical files as well). > > It does this already! After you clone a zone you should see a menu item to select a label. When you pick this you should see a list of available labels. When you pick one, it will automatically update tnzonecfg. There is no need to edit tnrhdb when a zone is created if you are using a shared IP address. Even if you have a per-zone address, the kernel will automatically associate it with the cipso template (but you'll get a syslog message). >One other thing that I have been playing with looking from a deployment >aspect is the ability to flop these files out and automatically install >them. I have the canned TN files and the canned xml files for the zone >creation and a script that goes and builds initial template zones and then >clones off multiple copies of each, but one area I am not so sure of is >the services configuration. We want to run minimal services in each zone >(for example, no sendmail running in our labeled zones). Currently the >only way I have discovered how to do this is to boot the zone and then >either import an xml file that sets most of those services off or, a new >thing I learned last week, to run "netservices limited" to run the "Secure >By Default" implementation (although I know that sendmail is still a >running service with that and I am not sure what the Secure by Default >stuff, which limits connections to localhost, does with the core TX stuff >like the MLD that require some connectivity with the global zone). After >creating and cloning the zones (we have 33 of them), the booting of the >zones will bring our machine to its knees as it attempts to configure >about 118 services in each zone. Further, with each zone, its svc.configd >runs at about 5~6% of the CPU, which seems like a lot when all the zones >are running at once. > >I'd like to see something that will clone each zone and initialize it in a >few minutes with extreme minimal services rather than the full suite that >it does now. Is there a way to place a specific xml file under the >/var/svc directory somewhere that will configure a very limited set of >services in the zone prior to that initial boot (sort of like what can be >done with /etc/sysidcfg) so that the first initialization doesn't take too >long? > > When you create your initial zone, you should Initialize it with the menu item and then bring up a Zone Console, and Start (boot) the zone. Login using the console and use svcadm disable to turn off sendmail, snmpx, dtlogin, etc. Then halt the zone and Create a snapshot of the completely initialized zone. When you clone new zones from this snapshot they will already have the same services disabled, and be initialized and ready to run PS. Grab a new copy of the txzonemgr script. I fixed a few bugs last night. --Glenn > > >>I have updated the Trusted Extensions website, >>http://www.opensolaris.org/os/community/security/projects/tx with a link >>to a new trusted zone manager. It's a ksh script with a simple zenity GUI >>that provides an intuitive framework for mantaining labeled zones; it can >>be used as an alternative to the various zone-related CDE actions that are >>included in the Trusted Extensions folder. >> >> Give it a try, and let me know what you think. >> >>--Glenn >> >> >>This message posted from opensolaris.org >>_______________________________________________ >>security-discuss mailing list >>security-discuss at opensolaris.org >> >> >> > > > >
