Hi
I need to assign proc_owner privilege to particular user through RBAC. How can I assign this privilege to user, I need help on this.
Further I need to understand if I give this proc_owner privilege to particular user, what kind of control user will get on other user or system processes which are not owned by him. What are the risks involved if we assign this privilege to user.
Regards
So the answer is: user can see all of the other processes & information & open files, etc. == yes
From: Privileges - Oracle Solaris Administration: Security Services
So, I would guess you do not want that. If in fact you do need it I'll dredge up some help. I have not even looked at this for about 3+ years....
Hi
Thanks for your input. Yes I need help in assigning this proc_owner privilege to user along with command. I would ne nice if you can provide help on this . Further I need to understand that whether user will only get the read access or it will also have write access to kill the process or get the power to switch the process id to uid 0. Further when I am going through the link provide by you, which said that "You should have overriding security reasons for placing such powerful privilege in the inheritable set of privileges for any user,role" . Will it create any security risk if this privilege is giving only read access to all the processes in the system.
Short answer to risk: yes. Not secure. That privilege means your power user reads the entire command line for ANY process, sometimes privileged processes get started something like this:
/path/to/foobar jon/password
The power user can get environment variables inside the process with pargs -e , so if the secure user has a password embedded in an environment variable the power user can see it.
That power user may under some circumstances also read some of the /proc files for other processes.
Sounds like a security problem to me. You will have to be certain that nowhere are there system scripts that require passwords passed to them or have them in a login variable or an envirionment variable, for example.
This privilege would be good on a development machine, not so good on a production box.
How to assign and un-assign
Turn off for user
usermod -K 'defaultpriv=basic,!proc_info' user
Turn on for user:
usermod -K 'defaultpriv=basic,proc_info' user
The difference is just a single ! character
Hi Jim
Thanks for your input along with commands. I was looking for proc_owner priviledge to be given to user but you have given proc_info to user instead of proc_owner.
Could you let me know how proc_info differ from proc_owner in term of security if I only want to give the read permission to user to see the process of system and other users
This is subject to privilege escalation - meaning it allows changes to some security settings for the process with proc_owner.
Privilege escalation - Wikipedia
That includes all of the information in /proc for a process, including for system processes.
May I ask what you are trying to accomplish? Sounds like you are trying to set up interactive users to monitor something.
Hi Jim
Its a new setup where app team need to monitor the processes running by different app users from specific user id to whom I have to give proc_owner priviledge
As per my testing on my VM machine proc_info privilege by default is given to every user so I think we need to give proc_owner priviledge.
Note: User1 and user2 created before running these commands only
root@sol11:~# usermod -K 'defaultpriv=basic,proc_owner' user1
user2@sol11:/proc$ ppriv -v $$
1020: -bash
flags = <none>
E: dax_access,file_link_any,file_read,file_write,net_access,proc_exec,proc_fork,proc_info,proc_session,sys_ib_info
I: dax_access,file_link_any,file_read,file_write,net_access,proc_exec,proc_fork,proc_info,proc_session,sys_ib_info
P: dax_access,file_link_any,file_read,file_write,net_access,proc_exec,proc_fork,proc_info,proc_session,sys_ib_info
L: contract_event,contract_identity,contract_observer,cpc_cpu,dax_access,dtrace_kernel,dtrace_proc,dtrace_user,file_chown,file_chown_self,file_dac_execute,file_dac_read,file_dac_search,file_dac_write,file_downgrade_sl,file_flag_set,file_link_any,file_owner,file_read,file_setid,file_upgrade_sl,file_write,graphics_access,graphics_map,ipc_dac_read,ipc_dac_write,ipc_owner,net_access,net_bindmlp,net_icmpaccess,net_mac_aware,net_mac_implicit,net_observability,net_privaddr,net_rawaccess,proc_audit,proc_chroot,proc_clock_highres,proc_exec,proc_fork,proc_info,proc_lock_memory,proc_owner,proc_priocntl,proc_session,proc_setid,proc_taskid,proc_zone,sys_acct,sys_admin,sys_audit,sys_config,sys_devices,sys_dl_config,sys_flow_config,sys_ib_config,sys_ib_info,sys_ip_config,sys_ipc_config,sys_iptun_config,sys_linkdir,sys_mount,sys_net_config,sys_nfs,sys_ppp_config,sys_res_bind,sys_res_config,sys_resource,sys_share,sys_smb,sys_suser_compat,sys_time,sys_trans_label,win_colormap,win_config,win_dac_read,win_dac_write,win_devices,win_dga,win_downgrade_sl,win_fontpath,win_mac_read,win_mac_write,win_selection,win_upgrade_sl
user2@sol11:/proc$
user2@sol11:/proc$
user2@sol11:/proc$ ppriv $$
1020: -bash
flags = <none>
E: basic
I: basic
P: basic
L: all
user2@sol11:/proc$
user1@sol11:/proc$ ppriv $$
1030: -bash
flags = <none>
E: basic,proc_owner
I: basic,proc_owner
P: basic,proc_owner
L: all
user1@sol11:/proc$
user1@sol11:/proc$ ppriv -v $$
1030: -bash
flags = <none>
E: dax_access,file_link_any,file_read,file_write,net_access,proc_exec,proc_fork,proc_info,proc_owner,proc_session,sys_ib_info
I: dax_access,file_link_any,file_read,file_write,net_access,proc_exec,proc_fork,proc_info,proc_owner,proc_session,sys_ib_info
P: dax_access,file_link_any,file_read,file_write,net_access,proc_exec,proc_fork,proc_info,proc_owner,proc_session,sys_ib_info
L: contract_event,contract_identity,contract_observer,cpc_cpu,dax_access,dtrace_kernel,dtrace_proc,dtrace_user,file_chown,file_chown_self,file_dac_execute,file_dac_read,file_dac_search,file_dac_write,file_downgrade_sl,file_flag_set,file_link_any,file_owner,file_read,file_setid,file_upgrade_sl,file_write,graphics_access,graphics_map,ipc_dac_read,ipc_dac_write,ipc_owner,net_access,net_bindmlp,net_icmpaccess,net_mac_aware,net_mac_implicit,net_observability,net_privaddr,net_rawaccess,proc_audit,proc_chroot,proc_clock_highres,proc_exec,proc_fork,proc_info,proc_lock_memory,proc_owner,proc_priocntl,proc_session,proc_setid,proc_taskid,proc_zone,sys_acct,sys_admin,sys_audit,sys_config,sys_devices,sys_dl_config,sys_flow_config,sys_ib_config,sys_ib_info,sys_ip_config,sys_ipc_config,sys_iptun_config,sys_linkdir,sys_mount,sys_net_config,sys_nfs,sys_ppp_config,sys_res_bind,sys_res_config,sys_resource,sys_share,sys_smb,sys_suser_compat,sys_time,sys_trans_label,win_colormap,win_config,win_dac_read,win_dac_write,win_devices,win_dga,win_downgrade_sl,win_fontpath,win_mac_read,win_mac_write,win_selection,win_upgrade_sl
user1@sol11:/proc$
--- Post updated at 12:12 AM ---
Hi Jim
My only concern is that proc_owner doesn't pose any risk other than seeing the process running by other user. If I can restrict that specific user to see only processes related to specific users on the system then it would be great.
I do not think there is a "group_proc" privilege. You are going to have to set up sudo and and specifically allow those users to become the user that runs the application. But then they can "tink" with the application process.
sudo -
man pages section 1M: System Administration Commands It is part of Solaris 11.
Suppose the app runs with appuser. sudo su - appuser is the command they would use. I assume they are already in the same group as appuser. Let's call that group "foo"
You will have read up on sudoedit and / etc/sudoers You grant the permission to become "appuser" based on the fact that they are only in the special group I mentioned, "foo". Actually appuser does not have to be in the "foo" group, but then you open up access to anything that appuser can do in its own group to these newcomers.