Maybe this has been answered already but I could not find any info on it.
I have a local user 'admin' that runs certain crons and processes. How can I set the role for that user so that it does not conflict with the GRSEC admin user role?
Thank you
Last edited by getlost on Mon Sep 26, 2011 3:43 pm, edited 1 time in total.
The names for special roles are arbitrary and never matched against real usernames on the system. In logs they are also marked as a special role. Though a special role with name "admin" is auto-added for use with the full learning system, there's no requirement elsewhere that an admin special role exist, or that it be named "admin".
Let me know if the RBAC system though is preventing you from having a user role with name "admin." That would be a bug and simple to fix.
This is what I have in my policy. Maybe I am doing something dumb here (most likely)
role admin sA subject / rvka / rwcdmlxi
role shutdown sARG subject / rvka / /dev /dev/urandom r /dev/random r /etc r /bin rx /sbin rx /lib rx /lib64 rx /usr rx /proc r $grsec_denied -CAP_ALL connect disabled bind disabled
role default subject / / h -CAP_ALL connect disabled bind disabled . . .
role admin u role_allow_ip 192.168.0.47/32 subject / { / h /bin x /dev h /dev/pts rw /dev/tty rw /etc r /etc/grsec h . . .
When running gradm -C I get
[root@localhost ~]# gradm -C The admin role has been marked as a persistent role. This severely compromises security as any process restarted via an admin role will retain the admin role indefinitely. Please create a specific role for the handling of system shutdown (the common use case of persistent special roles). The RBAC system will not be allowed to be enabled until this error is fixed.
It's possible, there just existed a bug in gradm that you demonstrated that made it falsely report the user role as a persistent role. It's been fixed in the latest version of gradm. Thanks for the report!