[desktop-discuss] [security-discuss] requirement for identifying a console user in RBAC

[Riny Qian]

The problem/requirement comes from the desktop group, and that is more
authorizations/privileges should be assigned to the local console
user, thus the console user can do some "powerful" jobs.

I'm not sure how it would affect TX or if it would break some security
policies.

Regards,
Riny

Glenn Faden wrote:
> I don't understand your requirement for dynamic authorizations. Please 
> describe the problem you are trying to solve. We already have an 
> authorization, solaris.system.shutdown, in the Maintenance and Repair 
> rights profile. Users who lack this authorization shouldn't be permitted 
> to shutdown the system. Are you suggesting that a user is implicitly 
> permitted to shutdown the system if they can login to the console?
> 
> --Glenn
> 
> Riny Qian wrote:
>> I think the purpose here is to provide the console user with some
>> authorizations/privileges so that he/she can run some admin tools
>> (e.g. gnome-sys-suspend, g-p-m, poweroff) successfully. Then there
>> are at least two questions to be answered:
>>
>> 1. Which admin tools should be provided to the console use? so that
>>     which authorizations/privileges should be assigned to the console
>>     user?
>>
>> 2. How to dynamically assign authorizations/privileges to the console
>>     user?
>>
>> For the second question, we may add supporting library functions (e.g.
>> console_role_login/console_role_logout, just like di_devperm_login/
>> di_devperm_logout for console devices permission) for login programs
>> (login, dtlogin, gdm) to dynamically assign required authorizations/
>> privileges for the logged in console user upon login/logout.  Maybe
>> there are better ideas.
>>
>> Another way to think about this purpose is that probably we can
>> add a supporting library function like is_console_user() for admin tools
>> which are identified to be used by the console user. Then these
>> admin tools may need to be turned into suid root programs or something
>> like that. This way requires the change to all admin tools, so it
>> doesn't look good.
>>
>> Regards,
>> Riny
>>
>> Lin Ma wrote:
>>  
>>> Hi,
>>>
>>> Currently we can see there are lots of requirements in system user-level
>>> for identifying a console user especially in the scope of admin tools,
>>> e.g. gnome-sys-suspend, gpm, nwam, etc. I think those tools would like
>>> to give console user the priviledge to use them. I know now we have to
>>> check the owner of /dev/console to identify in each application if
>>> necessary. But to be Solaris RBAC compliable, we'd better to use an
>>> auth_attr like solaris.device.console[.session] or whatever.
>>>
>>> So I think the best way is to hack login application (dtlogin, gdm,
>>> ttymon, etc). I've talked with Riny, he think all the login applications
>>> finally invoke console_role_log[in|out] to change the owner of
>>> /dev/console. If so, I think we can change those function to add the
>>> auth which I mentioned above to the login user. Riny told me if we have
>>> the requirement, we can set up a discussion to change those functions
>>> since they (Riny and his team) own them.
>>>
>>> But here're some tech issues. Since all the changes happen in user
>>> land. So I take a quick look of /usr/man/man3secdb (note I'm not good at
>>> SEC), I found there are no functions supporting temporary change the
>>> auths of a user. But in one of them mentioned libsecdb has an internal
>>> storage (I guess I can say it cache) of sec related information for a
>>> user. Since permanently changing /etc/user_attr for a console user is
>>> not a good idea, so maybe we need assistance of security team to evolve
>>> them.
>>>
>>> (We may make things complicate if we like. e.g. append a special
>>> role to a console user)
>>>
>>> Is it possible? Comments?
>>>
>>> lin
>>>     
>>
>> _______________________________________________
>> security-discuss mailing list
>> security-discuss at opensolaris.org
>>   
>