On Fri, May 22, 2009 at 4:32 PM, Clay Baenziger <clayb at sun.com> wrote:
> Hi Mike, > From a meeting on Derived Profiles, the question of security > compartmentalization came up. It would be useful to have your input -- and > any other folks too. We were discussing the snippet from your e-mail below: > > - I can trust that the just-hired-last-week junior sysadmin armed with >> a simple procedure can install Solaris per standards without risk of >> breaking the jumpstart environment for everyone else. That is, since >> there is no customization to perform on the jumpstart server there is >> no chance that someone that is not tasked with maintaining jumpstart >> will break jumpstart. >> > > First, we discussed how in AI current, adding any new system in AI will > change the install matrix, since AI follows an "always install" mentality > (we have the default manifest and will always try to give the client > something). Perhaps this is an undesirable feature moving into some > enterprise realms? > That is somewhat problematic. Historically jumpstart servers have been used as the "rescue disk" on the network. Introduction of something that will install automatically when you type "boot net" is really bad when sysadmins are trained that it is safe to do because "boot net - install" is the dangerous one. > Regardless, a junior sys. admin. might be tasked with changing something in > three separate ways: the criteria, the AI manifest or the SC manifest. It > seems some security here could prove useful, as the criteria may affect > which machines are installed, the AI manifest is what's installed and SC > manifest (root passwd, etc.) are how the machine is later configured and > accessed. Would there be value in allowing compartmentalization so that an > admin could only change say one of the three? I'm not so sure that I look at it with security as the primary goal, as the sysadmin that does the install will be logging in as root and doing whatever one-off configuration that is required. I look at it more from the quality standpoint. An individual server's quality may be compromised by a sysadmin doing the wrong one-off configuration on a server that was installed. Lots of servers quality can be compromised by a sysadmin doing the wrong thing on the jumpstart server. Compartmentalization as you describe could help drive that. It seems as though the AI manifest may have a higher bar to change it as this controls the image that is deployed. I assume that the image is a particular set of packages that has made it through a QA process. Lastly, moving AI to an "only install what's defined" system would allow one > to lock down the AI server so that an admin may only add a machine to the > server -- if it does not impede on the current install state space -- e.g. > it's a new machine not covered by a pre-existing manifest. Is this what you > meant from your e-mail? Or would this kind of control provide benefit? I don't think this is so much of a concern to me as machines are not repeatedly re-imaged. I can see it as more important in a lab environment where you need to repeatedly reimage certain machines to a known state, but that is not my world. I am much more concerned about ensuring that every machine that is installed gets one of the approved images. > If these didn't cover your intention, could you help me understand better > how AI could be modified to reach your goal? Having only done one AI installation, with a heads-up or flag-day since that time, I'm not sure exactly what changes are required. I don't see myself having a lot of time to try out more installations in the coming few weeks. My lab environment is pretty much all SPARC and I had very serious hoops to jump through to get my first AI installation to work due to lack of a procedure to use S10 or SXCE as the AI server. Installations are also rather slow because of the lack of a local mirror and rather steep hurdles to jump to establish one. The things that would help tremendously are: - Make everything accessible via http without funky protocols tunnelled over http. I have a hard time getting to mercurial repositories that are only available via ssh and pkg repositories that can only be mirrored via rsync. - Provide a means to get a proper install server up without step 1 being acquire new hardware installed on the same subnet as the servers to be installed. That is, either provide a way for running the AI server on S10/SXCE or provide an LDom image that can be used. Be sure I can download the LDom image over http without tunneling ssh or rsync over it. :) -- Mike Gerdts http://mgerdts.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090522/7f9a04c1/attachment.html>
