smf(5): authorizations built-in

I mentioned yesterday that you can manipulate services if you have the appropriate authorizations, without needing to possess any privileges. For instance, my current shell has the following privileges and authorizations:

$ ppriv $$
117292: bash
flags = 
        E: basic
        I: basic
        P: basic
        L: all
$ auths
solaris.device.cdrw,solaris.profmgr.read,solaris.jobs.users,solaris.mail.mailq

And if we try to manipulate a service managed by smf(5) with this set of authorizations, we'll get a predictable result.

$ svcadm restart network/smtp
svcadm: network/smtp: Permission denied.

However, smf(5) defines two big authorizations:

  • solaris.smf.manage, which allows the user to request a restart, refresh, or other state modification of any service instance, and
  • solaris.smf.modify, which allows the users to create or delete services and instances, as well as manipulate any of their property groups or properties.

(There are also lesser built-in authorizations—solaris.smf.modify.method, solaris.smf.modify.dependency, solaris.smf.modify.application, and solaris.smf.modify.framework—which allow the manipulation of properties within property groups of the mentioned type. And you can also customize the authorizations to allow an action at the instance level and to manipulate properties at the property group level.)

To make assigning batches of authorizations scale, the role-based access control facility (RBAC) allows the definition of rights profiles. (The definitions are contained in /etc/security/prof_attr, and the documentation is prof_attr(4).) The service management facility delives with two rights profiles we think are convenient:

$ grep \^Service /etc/security/prof_attr
Service Management:::Manage services:auths=solaris.smf.manage,solaris.smf.modify
Service Operator:::Administer services:auths=solaris.smf.manage,solaris.smf.modify.framework

We can then add the user_attr(4) database to connect a user with the appropriate profile, like:

$ grep sch /etc/user_attr
sch::::profiles=Service Management

(You can edit /etc/user_attr by hand or, if your password database is local, using the -P option to useradd(1M). The equivalent configuration via direct authorizations would read

$ grep sch /etc/user_attr
sch::::auths=solaris.smf.manage,solaris.smf.modify

and will work fine except that if the Service Management profile were to be enhanced subsequently, a user or role with the old explicity authorizations might not have the correct set for future operations.)

So now our authorization list is expanded, but our privileges are unchanged:

$ auths
solaris.smf.manage,solaris.smf.modify,solaris.device.cdrw,solaris.profmgr.read,solaris.jobs.users,solaris.mail.mailq
$ ppriv $$
117292: bash
flags = 
        E: basic
        I: basic
        P: basic
        L: all

and we can carry out our operation from an authorized, but unprivileged user account:

$ svcs network/smtp
STATE          STIME    FMRI
online         Sep_21   svc:/network/smtp:sendmail
$ svcadm restart network/smtp
$ svcs network/smtp
STATE          STIME    FMRI
online         23:58:21 svc:/network/smtp:sendmail

And, finally, since the user_attr(4) database has network name service backends, you can actually make authorization grants that apply across an administrative domain, whether you're giving out the big authorizations illustrated here or custom authorizations specific to a set of services running at your site.

Comments:

It's nice to see RBAC authorizations being used beyound the SMC GUI.

Sorry if I missed this, but in what build will SMF be integrated (or has it already ) ?

As a side note: I couldn't help but notice your shell is Bash. Don't you think it would be nice to add Bash to the "supported Solaris shells". That would certainly help people coming from Linux. It's true anyone can install SUNWbash but I am thinking about a Profile Shell and supporting bash officially, as part of the standard install.
For now, if I want people to use Bash but at some point assign some profiles to their user account either I have to change their login shell to pfksh or ask them to start one before invoking a privileged command. Is there any other method ? Would it be a lot of work to integrate and support Bash ?

Vlad

Posted by Vlad Grama on September 23, 2004 at 02:16 PM PDT #

@Vlad: smf(5) integrated in Build 64, but fair amount of follow-on work has gone into each build since then. It will be in the next release of Software Express for Solaris. Regarding bash (or zsh, which has a sizeable following in the kernel group, at least), I think that you've hit on a solid tactic--I'll go discuss it with the appropriate folks. - Stephen

Posted by Stephen Hahn on September 24, 2004 at 02:58 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

sch

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
External blogs