Amendments to pconsole fast-track [PSARC/2009/275 FastTrack timeout 05/08/2009]

[Leland Chen]

Gary,

    Please find my answers below.

    Thanks,

   Leland

> Norm,
>
> 	Sorry I didn't number my questions.  I agree a Rights Profile
> 	is far more in keeping with minimizing the attack surface of
> 	programs than making them suid.  Any how:
> 	1) To whom is the "Parallel Console Access" Rights Profile granted?
> 	2) How is the  "Parallel Console Access" Rights Profile granted to
> 	   users?
> 	   What I'm trying to get at here is:  Is Parallel Console Access
> 	   automatically granted and if so to whom?
>   
We, SunCluster added pconsole to OpenSolaris because the feedback from 
customers
and fields indicate that they prefer pconsole than cconsole, which is 
also a parallel remote
access console shipped along with Cluster bits.

The typical use case is a system admin uses pconsole/cconsole to do 
system level
configuration(such as shared disk and mount point), cluster software 
installation
and installation for the applications using the cluster. Usually these 
tasks are
same operations on multiple systems, and users are system admins who have
the root account privilege.  Actually, some of the application 
installation/configuration
type of tasks really don't have to have root privilege. For example, 
oracle DB
or Web/App server installation/configuration on multiple systems for the
cluster failover/scalable services.

For the 2nd question. I guess we expect system admins to assign 
"Parallel Console Access" profile
to the user accounts. For example, system admin could assign the profile 
to to oracle dba
account, so oracle DB admins with dba account can do the oracle 
configuration on a set of
systems.

> 	3) A help file needs to be part of creating this Rights Profile.
> 	   See:
>  	   http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/
>
>   
I will look at other examples to come up a help file.
> 	4) Conclusion on privs/uids.
> 	   Nit: the exec_attr entry s/suser/solaris/
> 	   Is it really the euid that matters, or is it that euid=0 gives
> 	   privs=all?  I don't know how to answer the tiocsti question.
> 	   I'm not sure that's this case (though it would be nice if
> 	   the policy was revisited and this case dependent on that revisit),
> 	   but I'm not suggesting that be the a case requirement.
>
>   
I am not familiar with this area. Hopefully, Norm/Tim can help on this.


> 	Perhaps an offline email if I've not been clear.
>
> Thankx,
> Gary..
>   
>> Gary Winiger wrote:
>>     
>>>> /etc/security/prof_attr:
>>>> Parallel Console Access:::Connect to remote consoles with pconsole:
>>>>     
>>>>         
>>> 	To whom/how is this Rights Profile granted?
>>>   
>>> 	Also note that a help file needs to come with the addition of
>>> 	a Rights Profile.  See:
>>> 	http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/
>>>
>>>   
>>>       
>>>> /etc/security/exec_attr:
>>>> Parallel Console Access:suser:cmd:::/usr/sbin/pconsole-bin:euid=0
>>>>     
>>>>         
>>> 	I've not seen a conclusion on privileges/uids.
>>>   
>>>       
>> It appears that unless the policy around TIOCSTI changes to allow the 
>> device owner to use it, then pconsole-bin needs to run with euid=0 to be 
>> useful.  It seemed like creating a rights profile for this and allowing 
>> assignment of that rights profile to a select set of users made more 
>> sense than making pconsole-bin suid root.  With a rights profile, our 
>> customers can control access to it by assigning this profile to users 
>> that have a need for pconsole.  With it suid root, anyone can use it and 
>> potentially use it to effectively hijack someone else's session.  With 
>> no rights profile and no suid root, you have to become root to use it.
>>
>> As for who is most likely to use it and therefore need access to the 
>> profile, I expect, based on the original case, it will be sysadmins 
>> managing clusters.
>>
>>     -Norm
>>
>>