Joe, Good Point. I'm wondering if all the existing admin procedures on the wiki should be changed to *not* use pfexec? Glenn, what do you think? Also, we are putting together the Getting Started Guide now, and pfexec instructions appear in several places in that book. I guess those are okay to leave, in light of what Joe just mentioned?
Nita On 03/28/09 08:58, Joseph Mocker wrote: > Perhaps some of the confusion comes because the OpenSolaris install > sets the initial user account to be Primary Administrator and there > are lots of examples of administration with pfexec like "pfexec pkg > image-update" > > -- joe > > > On Mar 28, 2009, at 7:42 AM, Glenn Faden <Glenn.Faden at sun.com> wrote: > >> Fredrich Maney wrote: >>> On Fri, Mar 27, 2009 at 6:05 PM, Glenn Faden <Glenn.Faden at sun.com> >>> wrote: >>> [...] >>> >>> >>>> It is a mistake to be telling users to constantly use pfexec. It >>>> was not >>>> designed for that purpose. We should be telling people to assume >>>> roles, via >>>> su, or to use sudo. >>>> >>> >>> I'm in the process of taking the root password away from several users >>> that shouldn't have it (application administrators). Since we are an >>> all Solaris shop (at least on the Unix side), I had planned on using >>> roles and judicious use of 'pfexec' to also remove our dependency on >>> 'sudo' at the same time. Is there some reason I shouldn't do that? >>> >>> fpsm >>> >> When you say that you are taking the root password away from users, I >> assume you mean that you will change it and not tell them. However, >> if you make root a role, then they can't su to root even if they know >> the password. When roles are assigned RBAC-aware shells, like pfsh, >> they don't need to call pfexec directly; it's done by the shell. >> >> Having normal users invoke pfexec directly presents the risk that any >> user application could also invoke it without the user's knowledge. >> It could be buried in a shell script, for example. That's why it is >> safer to use roles. >> >> --Glenn >> _______________________________________________ >> security-discuss mailing list >> security-discuss at opensolaris.org