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