Feature #13195
would like roleauth user_attr
100%
Description
When using RBAC, it would be useful to have an option to allow users to assume a role by authenticating with their own password rather than the password for the role.
This is a feature that has been requested a number of times for OmniOS, by users migrating from Solaris.
Updated by Andy Fiddaman 4 months ago
Testing notes:
On this system, af
is a standard user with no exceptional profiles or auths, but does have the root
role.
bloody% id uid=100(af) gid=1(other) bloody% roles root bloody% profiles Basic Solaris User All bloody% auths solaris.admin.wusb.read,solaris.device.cdrw,solaris.device.mount.removable,solaris.mail.mailq,solaris.profmgr.read
Let's switch root to be a role instead of a normal user:
bloody% userattr type root normal bloody% su - Password: OmniOS r151035 omnios-roleauth-114828c528 October 2020 You have new mail. root@bloody:~# root@bloody:~# usermod -K type=role root root@bloody:~# logout
Root is now a rule, and does not have a `roleauth` attribute (since it was created before this change)
bloody% userattr type root role bloody% userattr roleauth root bloody%
Test that af
can switch to the role using the role (root) password.
bloody% su - <-- root password Password: OmniOS r151035 omnios-roleauth-114828c528 October 2020 You have new mail. root@bloody:~#
Now set the new roleauth
attribute to user
.
root@bloody:~# rolemod -K roleauth=user root root@bloody:~# logout
Now, the user's password is required to switch to the role. The root password is not accepted:
bloody% su - <-- root password Password: su: Sorry bloody% su - <-- af password Password: OmniOS r151035 omnios-roleauth-114828c528 October 2020 You have new mail. root@bloody:~#
Checking that these events are audited with the proper audit event tags - (compared to a system without this patch)
root@bloody:~# praudit -s /var/audit/* header,69,2,AUE_su_logout,,bloody.citrus-it.net,2020-10-01 14:15:07.138 +00:00 subject,af,root,root,root,root,1162,2495023474,15989 136704 172.27.10.79 return,success,0 header,69,2,AUE_su,,bloody.citrus-it.net,2020-10-01 14:15:20.003 +00:00 subject,af,root,root,root,root,1169,2495023474,15989 136704 172.27.10.79 return,success,0 header,69,2,AUE_su_logout,,bloody.citrus-it.net,2020-10-01 14:15:27.030 +00:00 subject,af,root,root,root,root,1169,2495023474,15989 136704 172.27.10.79 return,success,0 header,69,2,AUE_role_login,,bloody.citrus-it.net,2020-10-01 14:15:31.068 +00:00 subject,af,root,root,root,root,1176,2495023474,15989 136704 172.27.10.79 return,success,0 header,69,2,AUE_role_logout,,bloody.citrus-it.net,2020-10-01 14:15:37.217 +00:00 subject,af,root,root,root,root,1176,2495023474,15989 136704 172.27.10.79 return,success,0 header,77,2,AUE_su,,bloody.citrus-it.net,2020-10-01 14:15:40.553 +00:00 subject,af,root,other,af,other,1183,2495023474,15989 136704 172.27.10.79 text,root return,failure,Authentication failed header,69,2,AUE_role_login,,bloody.citrus-it.net,2020-10-01 14:15:47.857 +00:00 subject,af,root,root,root,root,1184,2495023474,15989 136704 172.27.10.79 return,success,0
Create a new role and check what the roleauth
attribute is set to - should default to role
root@bloody:~# roleadd bob root@bloody:~# userattr roleauth bob role
Change the default roleauth
attribute for new roles to user
root@bloody:~# roleadd -D -K roleauth=user group=other,1 project=default,3 basedir=/home skel=/etc/skel shell=/bin/pfsh inactive=0 expire= auths= profiles=All limitpriv= defaultpriv= lock_after_retries= roleauth=user
and add a new role then confirm the new default was applied.
root@bloody:~# roleadd sue root@bloody:~# userattr roleauth sue user
Updated by Andy Fiddaman 4 months ago
Also test single user boot since this uses `su` to authenticate the console user. In this case, any user with the solaris.system.maintenance
authorisation can gain root console access using their own password, regardless of the status of the roleauth
attribute. I tested both values, here's one of them:
root@bloody:~# usermod -A solaris.system.maintenance af UX: usermod: af is currently logged in, some changes may not take effect until next login. root@bloody:~# userattr type root role root@bloody:~# userattr roleauth root role
Booting to milestone "milestone/single-user:default". Hostname: bloody Requesting System Maintenance Mode SINGLE USER MODE Enter user name for system maintenance (control-d to bypass): af Enter af password (control-d to bypass): <- af password single-user privilege assigned to af on /dev/console. Entering System Maintenance Mode Oct 1 14:20:55 su: 'su root' succeeded for root on /dev/console OmniOS r151035 omnios-roleauth-114828c528 October 2020 You have new mail. root@bloody:~#
Updated by Andy Fiddaman 3 months ago
In addition to the testing with explicit output above, I also tested using su
to switch to various users and roles, both as a normal user and root, to confirm that was unaffected.
Additional testing was performed with useradd -D
to confirm that the roleauth
attribute does not show up in the list of defaults, and does not end up in /usr/sadm/defadduser
.
Updated by Electric Monk 3 months ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
git commit 9e678d632bda8e6911719d88b7c2d44a886aba5b
commit 9e678d632bda8e6911719d88b7c2d44a886aba5b Author: Andy Fiddaman <omnios@citrus-it.co.uk> Date: 2020-10-12T15:56:16.000Z 13195 would like roleauth user_attr Reviewed by: Jason King <jason.king@joyent.com> Reviewed by: Marco van Wieringen <mvw@planets.elm.net> Approved by: Robert Mustacchi <rm@fingolfin.org>