Commitment: Secure By Default, Phase I (2004/368) Submitter: Craig Payne Owner: Gary Winiger SUMMARY ======= * Micro release binding for S10 with a question * Minor release binding without a question and is dependent upon LSARC 2005/... and it converging * Updating the 20 questions * Spec update to take care of the nits * Best practices update ISSUES ====== gw-5 Nits: (hopefully the committee will agree ;-) Interface Tables * the entry for the SMF upgrade file should read: /var/svc/profile/upgrade Contracted Project Private P 2002/547 * the entry for cde-ttdbserver is duplicated. * the entries for meta, metamed, metah are unrelated to L 2004/811 and will be corrected. * the entry svc:/applications/graphical-login/dtlogin/config/request_port is an exported interface from this project and is not defined in L 2004/811 * authorizations don't seem to have a stated taxonomy and many authorization strings were never arced auth_attr(4) was introduced in PSARC/1997/332 as Evolving. Presumably the authorization strings are at lease Evolving. It seems reasonable that the help files would be internal. * guidelines: the astring for the value_authorization should read 'solaris.smf.value.myservice' gw-6 questionaire #4. What is meant by ``SSH: root only via PAM''? * The project team states that the question asks about authentication - root login is allowed on the console. `SSH: root only via PAM'' is supposed to be the other way around. This should be updated. jdc-6 Many of the FMRIs are Unstable and some (such as svc:/network/rpc/calendar-manager:udp) seem to be gone from the system. How will these interfaces be kept in sync? (Related: should we just establish a rule that such interfaces can never be Unstable in the first place?) * For the FMRI that is defined by this case, the project team doesn't see how they cannot make these evolving. The p-team could raise the stability level with some restrictions. - Gary: Look at the guidelines to make the changes to the interfaces. jdc-7 [wes-1 follow-up] Doesn't more need to be done here? A new Big Rule is needed to stop future projects (ARC cases) from enabling anything by default, or we'll just need to do this project again in the future when more on-by-default things integrate. * Yes, more should be done and there should be something here that will stop future cases. This is more of a "soon to be written" best practice that will be part of the Greenline project. - Future cases should not be allowed and 20 questions should also be updated. Bill and Gary will work offline on this. The security questionnaire should be re-worded to make it less overbearing. jdc-8 Minor failure mode: if you're using LOG_FROM_REMOTE and your preference gets uploaded to SMF on upgrade, then reimporting the manifest will have the surprising effect of deleting previously-requested syslogd configuration. (Perhaps no good way exists to avoid compatibility breaks as we SMF-ize existing configuration.) * This case is kind of unavoidable. The project team is not changing the behavior of syslogd but if it is a fresh install, then the default does change. * Gary: On an initial install will anything be different on the SE default file? - Default file itself does not change and remains the same. The comments in the file will be extended to reflect the new reality in the initial install case. gw-7 svc:/applications/graphical-login/dtlogin config/request_port doesn't exist. Should this project use dtlogin/args? Should it create a new property config/local_only for th service? * The project team will use the existing arg property. wes-6 my understanding is that the existing miniroot contains some (disabled by default) services which can be enabled when needed for debugging. will these still be present? could sshd be substituted? (Talk to Jan Setje-Eilers; he had some strong opinions about this). * This is disabled right now in the miniroot. There would be no services enabled during the miniroot install. The project team is not planning on enabling anything extra at this point. They will go back and talk with Jan about this issue. wes-7 anyone other than me have strong opinions on which box should be checked by default in the s10 update screen? handsoff jumpstart configs clearly should behave the same, but if we have to ask, user interaction is required either way... * The default setting of the checkbox should match the default behavior - meaning you should get the same result of the jumpstart install and the initial install as well. VOTE ===== yes - glenn, bill, ed, bob, jim, shudong, gary no - abstain - NP - NEXT STEP ========= * Case has been approved. * Waiting need spec ===========================================================================