RBAC rebooting a server
So, in a followup to the Solaris RBAC configuration post, I wanted to show how quick and easy it is to configure RBAC. As an example, I’m going to be working with the Solaris reboot command, on the basis that many developers want to reboot their environments, but you don’t always want to give them root.
So, the basic steps are:
define a Profile
assign a command to the Profile
define a Role
assign the Profile to the Role
allow a user to use the Role
Easy stuff. First stage, let’s create the profile. Profiles live in /etc/security/prof_attr, and are a way to group together similar commands. If you look in that file, you’ll see a lot of existing profiles, which tie together common groups of Solaris commands.
Adding a new profile is easy - we just add an extra line to the end of that file:
# echo "Reboot:::Profile to reboot Solaris:help=" >> /etc/security/prof_attr
Breaking it down - the first field is the profile name, and the fourth field is the description. The rest of the fields don’t matter at this stage, for what we’re doing.
The new profile is useless without a command, so let’s add the Solaris reboot command. Commands associated with RBAC profiles live in /etc/security/exec_attr (can you see a pattern in the filenames yet?) and - again - this file is pre-populated with command Solaris commands, grouped by profile.
# echo "Reboot:suser:cmd:::/usr/sbin/reboot:euid=0" >> /etc/security/exec_attr
Breaking the fields down again:
first field is the profile name
second field is the security policy - in this case, standard superuser
third field is the type - in this case, it’s a command
sixth field is the full path to the command
final field is the effective user ID the command is executed as
So far, it’s all pretty straightforward. Now we have a profile, and we have a command associated with that profile. Now we need to create a role.
RBAC roles are essentially normal user accounts, which have a restricted shell, and associated profile(s). The restricted shell is there to apply all the execution privilege and audit trail RBAC goodness.
Adding a role is nice and easy:
# roleadd -m -d /export/home/reboot reboot
64 blocks
Note the command line options to roleadd are the same as used when adding a normal Solaris user with useradd.
We also need to give the role a password:
# passwd reboot
New Password:
Re-enter new Password:
passwd: password successfully changed for reboot
And now we can see the role has been added to /etc/passwd:
# grep reboot /etc/passwd
reboot:x:1001:1::/export/home/reboot:/bin/pfsh
So it looks almost exactly the same as a normal Solaris user. Now all we need to do is add a profile to the role. We do this with the rolemod command, which - again - is very similar to the normal usermod command:
# rolemod -P Reboot reboot
Details of which profiles are assigned to roles - and which roles are assigned to users - live in /etc/user_attr - so we can look in there to see the changes we’ve made:
# grep reboot /etc/user_attr
reboot::::type=role;profiles=Reboot
Finally we’ll add the role to our user account:
# usermod -R reboot tomk
UX: usermod: tomk is currently logged in, some changes may not take effect until next login.
And just look in /etc/user_attr to make sure the changes have been made:
# grep reboot /etc/user_attr
reboot::::type=role;profiles=Reboot
tomk::::type=normal;roles=reboot
We can use the roles command to see what roles we have available to us:
$ roles
reboot
However, logged in as myself I still can’t reboot the machine:
$ /usr/sbin/reboot
reboot: permission denied
And that’s because the profile is assigned to the role, not to my user account:
$ profiles
All
Basic Solaris User
The clue on how to use roles was in how they are created and stored - they’re just like normal users. So to access a role, we su to it:
$ su reboot
Password:
The moment we su to a role, the whole RBAC audit trail kicks in. Everything, from that initial su onwards, is logged and tracked. Unlike sudo, this logging continues, even if we change shells or become another user (if the role allows us to). It’s this unbreakable audit trail that makes RBAC so powerful.
Now that we’ve assumed a role, we can check out the profiles available to us:
$ profiles
Reboot
So we can now execute the reboot command and bounce the box:
$ /usr/sbin/reboot
Connection to 192.168.13.101 closed by remote host.
Connection to 192.168.13.101 closed.
Have a look at the configuration files and see all of the roles and profiles that come pre-configured with Solaris. Play about with them and get familiar with the terminology. RBAC isn’t difficult or complex - it’s just very different. Get comfortable with it and you’ll soon be able to leverage it’s power to really secure your Solaris machines without denying users any functionality
So, in a followup to the Solaris RBAC configuration post, I wanted to show how quick and easy it is to configure RBAC. As an example, I’m going to be working with the Solaris reboot command, on the basis that many developers want to reboot their environments, but you don’t always want to give them root.
So, the basic steps are:
define a Profile
assign a command to the Profile
define a Role
assign the Profile to the Role
allow a user to use the Role
Easy stuff. First stage, let’s create the profile. Profiles live in /etc/security/prof_attr, and are a way to group together similar commands. If you look in that file, you’ll see a lot of existing profiles, which tie together common groups of Solaris commands.
Adding a new profile is easy - we just add an extra line to the end of that file:
# echo "Reboot:::Profile to reboot Solaris:help=" >> /etc/security/prof_attr
Breaking it down - the first field is the profile name, and the fourth field is the description. The rest of the fields don’t matter at this stage, for what we’re doing.
The new profile is useless without a command, so let’s add the Solaris reboot command. Commands associated with RBAC profiles live in /etc/security/exec_attr (can you see a pattern in the filenames yet?) and - again - this file is pre-populated with command Solaris commands, grouped by profile.
# echo "Reboot:suser:cmd:::/usr/sbin/reboot:euid=0" >> /etc/security/exec_attr
Breaking the fields down again:
first field is the profile name
second field is the security policy - in this case, standard superuser
third field is the type - in this case, it’s a command
sixth field is the full path to the command
final field is the effective user ID the command is executed as
So far, it’s all pretty straightforward. Now we have a profile, and we have a command associated with that profile. Now we need to create a role.
RBAC roles are essentially normal user accounts, which have a restricted shell, and associated profile(s). The restricted shell is there to apply all the execution privilege and audit trail RBAC goodness.
Adding a role is nice and easy:
# roleadd -m -d /export/home/reboot reboot
64 blocks
Note the command line options to roleadd are the same as used when adding a normal Solaris user with useradd.
We also need to give the role a password:
# passwd reboot
New Password:
Re-enter new Password:
passwd: password successfully changed for reboot
And now we can see the role has been added to /etc/passwd:
# grep reboot /etc/passwd
reboot:x:1001:1::/export/home/reboot:/bin/pfsh
So it looks almost exactly the same as a normal Solaris user. Now all we need to do is add a profile to the role. We do this with the rolemod command, which - again - is very similar to the normal usermod command:
# rolemod -P Reboot reboot
Details of which profiles are assigned to roles - and which roles are assigned to users - live in /etc/user_attr - so we can look in there to see the changes we’ve made:
# grep reboot /etc/user_attr
reboot::::type=role;profiles=Reboot
Finally we’ll add the role to our user account:
# usermod -R reboot tomk
UX: usermod: tomk is currently logged in, some changes may not take effect until next login.
And just look in /etc/user_attr to make sure the changes have been made:
# grep reboot /etc/user_attr
reboot::::type=role;profiles=Reboot
tomk::::type=normal;roles=reboot
We can use the roles command to see what roles we have available to us:
$ roles
reboot
However, logged in as myself I still can’t reboot the machine:
$ /usr/sbin/reboot
reboot: permission denied
And that’s because the profile is assigned to the role, not to my user account:
$ profiles
All
Basic Solaris User
The clue on how to use roles was in how they are created and stored - they’re just like normal users. So to access a role, we su to it:
$ su reboot
Password:
The moment we su to a role, the whole RBAC audit trail kicks in. Everything, from that initial su onwards, is logged and tracked. Unlike sudo, this logging continues, even if we change shells or become another user (if the role allows us to). It’s this unbreakable audit trail that makes RBAC so powerful.
Now that we’ve assumed a role, we can check out the profiles available to us:
$ profiles
Reboot
So we can now execute the reboot command and bounce the box:
$ /usr/sbin/reboot
Connection to 192.168.13.101 closed by remote host.
Connection to 192.168.13.101 closed.
Have a look at the configuration files and see all of the roles and profiles that come pre-configured with Solaris. Play about with them and get familiar with the terminology. RBAC isn’t difficult or complex - it’s just very different. Get comfortable with it and you’ll soon be able to leverage it’s power to really secure your Solaris machines without denying users any functionality
No comments:
Post a Comment