illumos gate

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

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:~#

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.