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