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