William, Sounds good to me. My brief comment below.
Joe William Schumann wrote: > Joe, > > Joseph J VLcek wrote: >> William Schumann wrote: >>> Default values for user and root passwords were not encrypted as >>> called for in: >>> >>> - 4246 The user and root password are not encrypted in SC manifest >>> >>> http://cr.opensolaris.org/~wmsch/bug-6622/ >>> http://defect.opensolaris.org/bz/show_bug.cgi?id=6622 >>> >>> Edited default.xml in SUNW-installadm-tools to provide usable >>> encrypted passwords as described in bug report. >>> >>> user: jack password:jack >>> root password: opensolaris >>> >>> Also added code to provide the same values if they are absent from >>> the SC manifest for whatever reason. >>> >>> Informational debugging message in Orchestrator can now display the >>> passwords, since they are encrypted. >>> >>> Tested default.xml changes going into SUNWinstalladm-tools package >>> on x86 and SPARC. >>> Tested new auto-install and liborchestrator on x86 and SPARC. >>> Deleted entries from SC manifest and software generated correct >>> default values. >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> >> >> William, >> >> Set the commit comment prior to generating the webrev. (I used to >> forget to do this too. ;) >> >> Everything looks good... >> >> Just some nits. >> >> Hope this helps! >> >> Joe >> >> usr/src/cmd/ai-webserver/default.xml >> ++++++++++++++++++++++++++++++++++++ >> >> Suggestion, Please consider: >> ---------------------------- >> >> Is it considered safe to store encrypted defaults? > Well, I suppose that it's a usability question. It is not safe for an > uninformed user; however, many current users are evaluating AI and do > not want to have to go through the process of generating passwords and > placing them in manifests. Those concerned with maximum security will > change the passwords in the manifest, protect manifests from public > view, and change the passwords upon reboot. >> What if the encryption algorithm changes? > AI controls the encryption algorithm via /etc/security/policy.conf. > If the security policy were changed in the distro, the default.xml > passwords would also have to be changed to work. >> >> Since you added code to provide the defaults perhaps it might be >> safest to not list the encrypted defaults in the manifest. > Again, it is inherently unsafe to provide default passwords whether > they are encrypted or not. It is assumed that the concerned user will > override the defaults. Perhaps it is a bad idea to have the defaults > in the code: if the default passwords are not provided in the code, > the passwords could be removed from default.ini on the server so that > there are no defaults at all (although I don't think this would be > standard practice.) A custom distro could also have the default > passwords removed. > > So, I am backing out the embedded passwords in the code, so that if > passwords are not provided in a manifest, the install will fail. I > also backed out the logging statements exposing the encrypted > passwords in the log at an informational logging level. What do you > think? This seems to me to be the correct thing to do. >> >> Question: >> --------- >> >> Do/should we provide a mechanism or instructions for a user to >> generate the encrypted passwords if they want something besides the >> defaults? > I have already provided instructions for this in the AI setup HTML > page and the design document. >> >> usr/src/cmd/auto-install/auto_install.c >> +++++++++++++++++++++++++++++++++++++++ >> >> Comments on line 580 and 598 are the same. 598 should be changed from: >> 598 /* load user name from manifest or 'jack' */ >> >> To: >> 598 /* load user login name from manifest or 'jack' */ >> > Changed. > > Thanks, Joe. Please review the modifications. > William
