[OpenIndiana-discuss] oi151 clean install - root role problem

Mon Nov 28 04:59:43 UTC 2011

Agreed. 

We have the choice of either, but often the organizations policy
dictates the choice even if it does not seem to make sense. When root
account access is forbidden, Primary Administrator allows someone the
check the box in their security list. 

More importantly, Primary Administrator can have its permissions changed
ie. reduced, while root can not. Root has and always will have full
access, Primary Administrator can be restricted.

"RBAC mechanisms can be used by a system administrator in enforcing a
policy of
separation of duties. Separation of duties is considered valuable in
deterring fraud since
fraud can occur if an opportunity exists for collaboration between
various job related
capabilities. Separation of duty requires that for particular sets of
transactions, no single
individual be allowed to execute all transactions within the set. The
most commonly used
examples are the separate transactions needed to initiate a payment and
to authorize a
payment. No single individual should be capable of executing both
transactions.
Separation of duty is an important consideration in real systems. [1] ,
[12] , [13] , [14]
The sets in question will vary depending on the application. In real
situations, only
certain transactions need to be restricted under separation of duty
requirements. For
example, we would expect a transaction for ``authorize payment'' to be
restricted, but a
transaction ``submit suggestion to administrator'' would not be."
David Ferraiolo and Rick Kuhn

Separation of Duties can be applied to system administration, not just
"Users".

What ever it is you want to do, Openindiana gives you the choice.
If you do not like the defaults, change it. Are the defaults correct?
That depends on your requirements so there are no correct defaults.

Mike

On Mon, 2011-11-28 at 01:09 -0300, Ignacio Marambio Catán wrote:

> by that reasoning, if you wanted a primary administrator, you'd assign
> the root role and be done with it.
> 
> On Mon, Nov 28, 2011 at 12:50 AM, Michael Stapleton
> <michael.stapleton at techsologic.com> wrote:
> > Hello,
> >
> > I have to disagree that having Primary Administrator was a blunder. How
> > it is used is a blunder. Primary administrator should never be assigned
> > to a user account. In reality, no special privileges should be assigned
> > to user accounts. Privileges/Profiles/Authorizations/Rights should only
> > be assigned to Roles, and users account assigned Roles.
> >
> > In a high security environment, no one person is completely trusted.
> > Administration of a server is separated between at least two people, a
> > system administrator and a security administrator. The root account does
> > not allow this separation of access and control. At least two Roles
> > would be created each with the appropriate rights. Then at least two
> > users accounts would be created, one for each person. if a persons job
> > is security, their account would be assigned the security Role, and if
> > they were an administrator, the admin Role. If a person changed roles
> > with in the organization, the Roles assigned to their user account would
> > be changed. The root account would almost never be used, and the
> > password would be highly controlled by a select few.
> >
> > This is the idea behind RBAC. Role Based Access Control.
> >
> > Security and convenience, Pick One.
> >
> >
> > Michael Stapleton
> >
> >
> >
> >
> > On Sun, 2011-11-27 at 20:07 -0300, Ignacio Marambio Catán wrote:
> >
> >> On Sun, Nov 27, 2011 at 7:56 PM, Matt Connolly
> >> <matt.connolly.au at gmail.com> wrote:
> >> >
> >> > On 28/11/2011, at 1:35 AM, Bill Sommerfeld wrote:
> >> >> On 11/27/11 04:36, Matt Connolly wrote:
> >> >>> This still didn't help. But again, setting the root user password with `sudo passwd root` enables me to authenticate to the root role using that root password. (not my user password, as I would use with sudo).
> >> >>>
> >> >>> Any reason why the installer would not give the "Primary Administrator" profile to the first user on the machine?
> >> >>
> >> >> A user account granted the "Primary Administrator" profile becomes equivalent to root -- any process running as that uid can "pfexec rm -rf /usr" or anything more destructive.
> >> >>
> >> >> > If the first user can't do it, who can?
> >> >>
> >> >> Primary Administrator is too powerful to grant to a "use every day" user account.
> >> >
> >> > Granted. Although I would think an option during the install process to grant "Primary Administrator" role to that first user (perhaps with an appropriate warning) would be fine. (As far as risk goes, the first user is given access to root via sudo anyway).
> >> >
> >> > I'm happy using sudo because it asks to confirm password (which pfexec doesn't), but I see two caveats with that:
> >> > 1. no support for role based auditing
> >> > 2. all the existing system panels use the role/profile approach.
> >>
> >>
> >> I do not know how sudo is compiled in openindiana but sudo has proper
> >> support for BSM, patches have been submitted for that in 2008
> >> seriously, the primary administrator thing was an extremely bad idea.
> >> Oracle fixed that particular blunder with solaris 11 making su work
> >> like sudo for the most part
> >>
> >> >
> >> >>
> >> >>> If it wasn't for sudo, you'd have to boot into single mode to change anything!
> >> >>
> >> >> the folks who made the opensolaris installer grant the first regular user the "primary administrator" role, and then splattered pfexec all over the documentation, made a terrible mistake; the installer has only been corrected recently, after too many opensolaris users have been mistrained to use pfexec the wrong way.
> >> >
> >> > And finally, just to clarify one more thing, when you use those system panels (like SMF Services, etc) that ask you to authenticate as root role, should it be the root password or your user password?
> >>
> >> to login to a role, you need the role password
> >>
> >> >
> >> > Thanks,
> >> > Matt
> >> >
> >> >
> >> > _______________________________________________
> >> > OpenIndiana-discuss mailing list
> >> > OpenIndiana-discuss at openindiana.org
> >> > http://openindiana.org/mailman/listinfo/openindiana-discuss
> >> >
> >>
> >> _______________________________________________
> >> OpenIndiana-discuss mailing list
> >> OpenIndiana-discuss at openindiana.org
> >> http://openindiana.org/mailman/listinfo/openindiana-discuss
> >
> >
> > _______________________________________________
> > OpenIndiana-discuss mailing list
> > OpenIndiana-discuss at openindiana.org
> > http://openindiana.org/mailman/listinfo/openindiana-discuss
> >
> 
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss