UNIX Consulting and Expertise
Golden Apple Enterprises Ltd. » Posts for tag 'rbac'

Allowing Normal Users to Manage SMF Services: Part 2 Comments Off on Allowing Normal Users to Manage SMF Services: Part 2

In Part 1, I covered setting up RBAC with a custom role that would allow us to manage an SMF service as a non-privileged user. Now I’ll cover the steps required to setup the SMF part.

Note that, in the previous post, for management of the Sun MC Agent, we didn’t add a specific command – we added an authorisation to the Profile.

Although this will configure RBAC to support this nicely, it actually won’t do anything – we need to specifically configure SMF on each host to support this extra authorisation.

Basically SMF has an all or nothing approach – applying the authorisation solaris.smf.manage will allow you to manage any SMF service – very much not what we want.

Instead we want to configure a specific SMF service – in this case, sunmcagent – to allow an authorisation string that lets us specifically manage this service – and just this service.

We do this by using the svcprop command on the specific host to directly edit the properties of the service.

First of all let’s list the service’s properties:

root@madlarry # svcprop -p general sunmcagent
general/enabled boolean true
general/entity_stability astring Evolving
general/single_instance boolean true

All fairly straightforward – the above tells us:

  • the service is enabled
  • it’s an evolving service, so the stability of it’s properties isn’t guaranteed
  • there can only be a single discreet instance of this service

We want to add an additional property, our authorisation string.

We use the svccfg command to do this:

root@madlarry # svccfg -s sunmcagent setprop general/action_authorization=astring: 'solaris.smf.manage.sunmcagent'

Having done this, it won’t take effect until we refresh the service.

Check for yourself:

root@madlarry # svcprop -p general sunmcagent
general/enabled boolean true
general/entity_stability astring Evolving
general/single_instance boolean true

Then we refresh the service:

root@madlarry # svcadm refresh sunmcagent

And then check again:

root@madlarry # svcprop -p general sunmcagent
general/enabled boolean true
general/entity_stability astring Evolving
general/single_instance boolean true
general/action_authorization astring solaris.smf.manage.sunmcagent

Behold our authorisation string! Now SMF will recognise this string when passed from RBAC, realise we only want to manage this specific service, and the magic happens.

However – we still can’t disable this service.

That’s because the ‘disable’ action modifies the SMF service (by changing the value of the general/enabled property) – the other actions are all temporary, but disable is persistent across reboots.

To get round this we need to add another property, value/authorization, will gives us authority to modify the values for properties for that specific service when managing it.

Similar sort of options to svcprop to affect this change:

root@madlarry # svccfg -s sunmcagent setprop general/value_authorization=astring: 'solaris.smf.manage.sunmcagent'

Then we can refresh and review the change:

root@madlarry # svcadm refresh sunmcagent
root@madlarry # svcprop -p general sunmcagent
general/enabled boolean true
general/entity_stability astring Evolving
general/single_instance boolean true
general/action_authorization astring solaris.smf.manage.sunmcagent
general/value_authorization astring solaris.smf.manage.sunmcagent

So now the authorisation ‘solaris.smf.manage.sunmcagent’ is allowed to perform temporary actions and permanently modify the values of the sunmcagent service.

There’s a good BigAdmin article on configuring custom RBAC roles in Solaris here – highly recommended reading.

Allowing Normal Users to Manage SMF Services: Part 1 Comments Off on Allowing Normal Users to Manage SMF Services: Part 1

RBAC doesn’t just let you give mortal users the power to execute commands as a privileged user – it can also be used to allow them power over other areas of the Solaris OE. A recurring task is allowing a normal user the power to start/stop an SMF service.

In this example I’ll work through how to allow a non-privileged user to manage the SMF service using by the Sun Management Centre (SMC) agent. We do this by modifying the SMF service to add an authorisation, and then defining with RBAC who is able to use that authorisation.

Setting up RBAC for this will involve modifying three of the RBAC configuration files:

  • /etc/security/prof_attr (where RBAC Profiles are defined)
  • /etc/security/auth_attr (where authorisations used by RBAC are defined)
  • /etc/user_attr (where user attributes are defined)

First of all, we need to edit /etc/security/prof_attr to add a new profile for the SMC agent. The syntax is simple: the name of the profile, a description, and then any authorisations that are needed. Adding the following line will do the trick:

SunMC Management:::Manage SunMC:auths=solaris.smf.manage.sunmcagent

Authorisations are extra tags that are added to an SMF service’s properties – they’re the ‘glue’ that ties together the profile and the SMF service.

Next up we need to add a definition for the new authorisation, by editing /etc/security/auth_attr and adding the following line:

solaris.smf.manage.sunmcagent:::Manage SunMC Agent::

Finally, we edit /etc/user_attr to add in a new role, and then assign our newly created SMC Profile to the role. Add the following line to the file:

smcmgmt::::type=role;profiles=SunMC Management,All

Also within /etc/user_attr we need to assign the role to our users. Add in an entry for each user you want to be able to use the role, like this:

tom::::type=normal;roles=smcmgmt

The final stage required to setup RBAC is to add the role details to /etc/passwd and to add a group entry to /etc/group. This should be standard stuff, so I’ll just show the lines added to each file:

/etc/passwd

smcmgmt:x:10003:10003:SunMC Management RBAC Role:/export/home/smcmgmt:/bin/pfksh

/etc/shadow

smcmgmt:lku7RuB1d71jY:13162::::::

/etc/group

smcmgmt::10003:

As always for RBAC, it’s good practice to create a role, and get users to su to that, rather than tacking profiles onto existing users and pre-pending pfexec to each command.

That’s all for part one – we’ve setup RBAC and we’re ready to roll. Part 2 will cover how we actually modify the SMF service and tie everything together.

Update: You should also head over to Ben Summers’ blog, where he wrote up an excellent end-to-end guide on how to Control untrusted processes with Solaris SMF

RBAC examples – rebooting a server Comments Off on RBAC examples – 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:

  1. define a Profile
  2. assign a command to the Profile
  3. define a Role
  4. assign the Profile to the Role
  5. 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.

Solaris RBAC configuration 1 comment

RBAC is Roles Based Access Control for Solaris. It’s similar to sudo in that it allows you to let specific users enhance their privileges to run specific tasks.

RBAC has been around in Solaris for a long, long time. It’s matured nicely and is now very accessible and usable – once you get your head round the concepts. It’s very powerful and it’s an under-used framework which really needs to be understood more.

Unlike sudo RBAC can be integrated into NIS or LDAP, and provides a much more comprehensive framework out of the box for doing things.

The basic tasks to setup RBAC are:

  1. define a ‘Profile’ in prof_attr
  2. tie specific commands to that profile in exec_attr
  3. tie specific authorisations to that profile in auth_attr
  4. tie the profile to a role, then that role to a user(s) in user_attr
  5. or tie the profile directly to a user in user_attr

There are some tradeoffs between using Roles vs. adding Profiles to user:

  • Roles require a user to su to another user to execute the command
  • when many users need to do the same thing that requires several different Profiles, it’s easier to change the Role once to add more Profiles than to edit many users to add the same extra Profiles to all of them
  • easier to track who has access to what by using Roles rather than assigning things direct to users

Personally, when doing more than one thing, I like to define a Role, and then make users su to that Role. It makes management and scalability that much easier, and also more clearly defines who can do what.

It also continues the paradigm of having to su to another user to gain extra privileges. Keeping things working the same as they have done previously is the easiest way to introduce new methods of working, and new technologies, to the users whilst avoiding complaints :-)

In the next few posts I’ll cover some basic RBAC setup, and then adding RBAC configuration to allow a non-privileged user to control Solaris services via SMF.

A quick introduction to Solaris Comments Off on A quick introduction to Solaris

One last post before Christmas. Lately I’ve been seeing lots of Linux admins coming to Solaris boxes and getting confused – unable to find the right commands, unaware of the Solaris tools, generally just struggling to get to grips with an unfamiliar operating environment.

I rate Solaris very highly – it comes with some amazing tools, and is superbly tuned to the needs of the enterprise. This isn’t always aligned with the needs of developers and hackers, though – but once you get comfortable with the tools in Solaris, you’ll start to wonder how you managed without them.

I was going to type up a nice long document, but then I remembered that Ben Rockwood, over at Cuddletech, had already written An Accelerated Introduction to Solaris 10.

It’s a good read, and should help bring anyone up to speed who has a Linux background. One thing – please please take the time to read up on RBAC (linked from Ben’s post). RBAC is infinitely more powerful than sudo, and you will find RBAC+LDAP a totally invaluable skill to use within the datacentre.

Top of page / Subscribe to new Entries (RSS)