Gary Winiger wrote: > Dave, > >> Gary Winiger wrote: >>> Sorry, just catching up, so I may be repeating stuff already covered and >>> I know I've gotten long winded. >>> >>> Gary.. >>> ====== >>> First off, what seems to me to be necessary is a clear definition of >>> the target use for the OpenSolaris live CD install. It seems like it >>> could range anywhere from the high school student on a $500 single user >>> laptop to the multi-user enterprise customer in a highly secure environment >>> (think banking where it's your personal $$ that will be lost). >>> >>> IMO, they may have entirely different requirements. What is the vetted >>> requirements document for the project? >>> >> The graphic installer on the live CD is oriented at desktop/laptop >> users. The forthcoming text installer is oriented at server-class systems. > > Unfortunate that both are not the same. I here an implication > here that the GUI will install a system with a different policy > than the text based installer. That's unfortunate as well. It > would seem to me that Solaris folk would first see it on a more > personal system and then recommend it for their enterprises. >
I don't see it as unfortunate in any way - the users of each have different requirements, attempting to meet both in one interface often, if not always, satisfies neither. Whether they install with the same policy is open to discussion; since the target users are different, divergence in default policy could be appropriate. It's not necessarily my first choice, however. >>> Secondly, it seems to me a clear definition of the administrative model >>> for OpenSolaris is needed. This also could range from sudo/su root does >>> everything to the administrative user is granted a set of authorizations >>> and commands that let them setup just what can be done by whom without >>> having to resort to running interactively with privilege. >>> >>> IMO, they may be at different ends of the of the spectrum. What is the >>> vetted administrative model for OpenSolaris? At one time I was told that >>> Craig Payne was the Engineering manager in charge of defining the model. >> Some engagement there would be helpful. I've heard little of that in >> the 2 years we've worked on building OpenSolaris releases. > > craig.payne at sun.com. I've pushed from my internal side. Perhaps a > pull from y'all. > >> Absent other engagement, the anticipated direction has been essentially >> what you refer to below as "MacOS X style". > > Until the system is administered 90% through authorization driven > interfaces, the MacOS X style of no root login isn't likely to be > realizable. I'd recommend going with the next closest thing in the > Solaris RBAC model: PASSREQ=YES; root has a password and is a role; > the initial (admin) user is granted the root role and no special > Rights Profiles. > I should have clarified that configuration of sudo rather than a profile was anticipated for OpenSolaris desktops & laptops, based on familiarity. As noted by Darren earlier in the thread, some authorizations would still be required in order for single-user login to work. Dave > Gary.. >>> Without these two areas vetted, any suggestions may need significant >>> adjustment. >>> >>> Reading snippets from Greg Lavender and Bill Nesheim today: >>> Greg: >>> Our job is to continue to advance Solaris as the market leading >>> enterprise OS, exploiting Sun hardware innovations, as well as create >>> innovative OS-based technologies that enable market winning integrated >>> software+hardware systems, such as the S7000 family of storage >>> appliances and other that are to be determined. >>> >>> Bill: >>> I intend to call our new organization Solaris Platform Engineering. I >>> believe that this is a very suitable name both in the sense that we >>> continue to be responsible for delivering low level support for Systems >>> group Platforms, and also in the sense that the Solaris OS releases we >>> deliver serve as a stable Platform for application deployment. >>> >>> I'm not sure if they are targeting S10, OpenSolaris, Solaris Next with >>> their comments, but it would seem to me that the direction is more toward >>> the multi-user enterprise than the single user laptop. With that in mind, >>> my suggestions for the installed OpenSolaris, Solaris Next system are: >>> 1. /etc/default/login:PASSREQ=YES >>> 2. The current Nevada enforcement for PASSREQ=YES continue unchanged >>> 3. The installer require root to have a password -- see the >>> alternatives below. >>> 4. An initial user account be generated which requires a password. >>> That account is granted the root role and no explicit Rights >>> Profiles. >>> 5. That the user be given instructions how to set up a passwordless >>> "single user system" if they wish. >>> >>> That's pretty much how I manage my Solaris Boxes. >>> >>> An alternative is the Mac OS X style -- not using Solaris RBAC features as >>> the primary mechanism: >>> 1 and 2 as above >>> 3. Deliver root as a "no login" account. (passwd -N equivalent) >>> 4. An initial user account be generated which requires a password. >>> The initial account is given a user_attr(4) entry that grants the >>> "solaris.system.maintenance" authorization to the user. >>> (See PSARC/2008/321 No Root Login) >>> 5. The initial account is granted sudo(1m) access. >>> >>> I've not looked closely under the covers of Mac OS X, but that's >>> how it feels like Mac OS X works to me except Mac OS X does most things >>> through GUIs that require administrative authentication. >>> >>> And now my hoped for alternative which requires (and is aligned with) my >>> hoped for vetted administrative model: >>> 1 through 4 as directly above with slight modification that >>> the initial user is granted sufficient authorizations to configure >>> the system. >>> 5. administer the system by authorization driven interfaces that >>> provide separation of duties rather than the administer running >>> a shell with privilege. >>
