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


Reply via email to