On Wed, May 27, 2009 at 11:34 AM, Ethan Quach <ethan.quach at sun.com> wrote: > > > Mike Gerdts wrote: >> >> On Fri, May 22, 2009 at 4:32 PM, Clay Baenziger <clayb at sun.com >> <mailto: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. > > We ought to consider this. ?We currently don't have a concept of using > the AI boot image purely just as a "net boot" but as we refactor these > pieces, I think a generic "net boot" component may fall out of it. > >> >> ? ?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. > > If this one-off configuration is in the derivation script (the Begin script > in Jumpstart world), and that script is used for multiple install > clients, you still have risk of this one change impacting multiple > install clients though right?
The idea is that there is no reason to modify the Begin script. It just does the right thing. When that doesn't work, the begin script is copied to a Special_profiles directory (one of the few directories writable by non-root) and the rules file is updated with a simple "hostname" rule in the section of the rules file that says "Put you custom rules here. They should look like ...". The times that such things are needed tend to be when testing out a new platform. For example, before the Begin script understood what an LDom was I made quick hacks to a customized begin script without whacking the one that was used by standard installations. The Finish script may also have a role. For example, if I have a sun4u-specific package that needs to be installed with "pkgadd -G" it is easiest to do this via a finish script. >> Lots of servers quality can be compromised by a sysadmin doing the wrong >> thing on the jumpstart server. > > Thanks for clarifying your point. ?This sounds like it has bigger > scope in that it's a requirement for the AI ecosystem as a whole; > in Jumpstart, you seem to be using derived profiles to fulfill this > requirement. Derived profiles are an important part. There are policy and other technical components as well. > So from the derived manifest point of view, what it sounds like > you want is for the derivation process layer to not hinder isolation > of a client's configuration if it was set up that way. Correct. -- Mike Gerdts http://mgerdts.blogspot.com/
