Rights Profiles

A Rights Profile gives a user or role the privileges to perform one or more specified tasks. As the Primary Administrator of your system, you might not give rights profiles much thought because you basically have the authority to do everything. However, if you're creating accounts for other users on the system, it's unlikely that you want to also give them Primary Administrator powers.

A Rights Profile is comprised of authorizations and execution attributes, each of which are defined in a separate database. That is, to understand the full definition of a Rights Profile, you have to look at 2 files: profile attributes (prof_attr) and execution attributes (exec_attr).

Profile Attributes

The profile attributes are defined in the file /etc/security/prof_attr. There's a single record for each rights profile that contains a brief description of the profile, a list of authorizations associated with the profile and a pointer to a help file with additional information. For example, if we look at the Audit Review record in prof_attr:

Audit Review:::Review Solaris Auditing logs:auths=solaris.audit.read;help=RtAuditReview.html

We can see that users or roles assigned the Audit Review profile will have the solaris.audit.read authorization. The localized help files can be found in /user/lib/help/profiles.

Profile attributes can also be nested, such that one profile can refer to another. For example, the System Administrator profile doesn't list any authorizations directly, but is rather a collection of other rights profiles:

System Administrator:::Can perform most non-security administrative tasks:profiles=Audit Review,Printer Management,Cron Management,Device Management,File System Management,Mail Management,Maintenance and Repair,Media Backup,Media Restore,Name Service Management,Network Management,Object Access Management,Process Management,Software Installation,User Management,Project Management,All;help=RtSysAdmin.html

When a rights profile includes authorizations, you can get a description of that authorization by looking in the authorization attributes database, auth_attr.

The authorization attributes are defined in the file /etc/security/auth-attr and essentially contain a description of the authorization and a help file. For example, if we look at the solaris.audit.read authorization:

solaris.audit.read:::Read Audit Trail::help=AuditRead.html

We can see that users or roles with the solaris.audit.read authorization are allowed to read the audit trail. The localized audit read help file can be found in /usr/lib/help/auths.

Execution Attributes

The other half of a rights profile definition are the execution attributes. The execution attributes are defined in the file /etc/security/exec_attr and as the name implies, lists the commands that users or roles assigned the rights profile are allowed to run. In addition, the commands can be specified to run with alternative user ids and/or privileges. For example, if we look at the Audit Review records in exec_attr:

Audit Review:suser:cmd:::/usr/sbin/auditreduce:euid=0
Audit Review:suser:cmd:::/usr/sbin/auditstat:euid=0
Audit Review:suser:cmd:::/usr/sbin/praudit:euid=0

Users or roles assigned the Audit Review rights profile can execute auditreduce, auditstat and praudit using effective user ID 0. By setting the effective user ID, the command still runs with the real user ID of the logged-in user. So, for example, user tstark, using the Audit Review rights profile, can execute praudit as root (uid 0).

Graphically, the relationship between these files looks as follows:

Rights Profiles in Action

As an example, let's say we create a new role on our system for the purpose of reviewing the audit:

bleonard@os200906:~$ pfexec roleadd -m -d /export/home/auditor -s /usr/bin/bash auditor
80 blocks
bleonard@os200906:~$ pfexec passwd auditor
New Password: 
Re-enter new Password: 
passwd: password successfully changed for auditor

And then we hire a new employee who will be responsible for auditing the system:

bleonard@os200906:~$ pfexec useradd -m -d /export/home/tstark -s /usr/bin/bash -R auditor tstark 
80 blocks
bleonard@os200906:~$ pfexec passwd tstark
New Password: 
Re-enter new Password: 
passwd: password successfully changed for tstark

Now, if tstark logs into the machine and tries to review the audit trail:

bleonard@os200906:~$ ssh -X tstark@os200906
Last login: Tue Jun 22 10:29:13 2010 from os200906
Sun Microsystems Inc.   SunOS 5.11      snv_111b        November 2008
tstark@os200906:~$ su - auditor

auditor@os200906:~$ pfexec /usr/sbin/praudit /var/audit/20100621202538.not_terminated.os200906 
praudit: Can't assign /var/audit/20100621202538.not_terminated.os200906 to stdin.

He's not allowed to do so (although the message isn't very clear as to why).

If we look at the auditor's profiles, we see he's still just a Basic Solaris User:

auditor@os200906:~$ profiles
Basic Solaris User

So now let's add the Audit Review profile to the auditor role and try again:

bleonard@os200906:~$ pfexec rolemod -P "Audit Review" auditor

And now our auditor can successfully print the audit trail:

auditor@os200906:~$ pfexec /usr/sbin/praudit /var/audit/20100621202538.not_terminated.os200906 
file,2010-06-21 16:25:38.984 -04:00,
header,44,2,system booted,na,2010-06-21 16:23:25.458 -04:00
text,booting kernel
header,69,2,login - local,,localhost,2010-06-21 16:27:25.183 -04:00
subject,bleonard,bleonard,staff,bleonard,staff,477,3112795690,0 0 localhost
header,69,2,login - local,,localhost,2010-06-21 16:28:24.881 -04:00
subject,bleonard,bleonard,staff,bleonard,staff,615,3530634311,0 0 localhost

Let's try to do something else, like disable the audit:

auditor@os200906:~$ svcadm disable auditd
svcadm: Unexpected libscf error on line 499: insufficient privileges for action.

This response is appropriate. We've only given our auditor the authority to review the audit records, not control them. If we look at the authorizations required required to manage the audit service:

auditor@os200906:~$ svcprop auditd | grep authorization
general/action_authorization astring solaris.audit.config

And then look at the auditor's authorizations, you'll see that we have the solaris.audit.read, but not solaris.audit.config:

auditor@os200906:~$ auths

The solaris.audit.config authorization is defined as part of the Audit Control rights profile:

Audit Control:::Configure Solaris Auditing:auths=solaris.audit.config,solaris.jobs.admin,solaris.admin.logsvc.purge,solaris.admin.logsvc.read;help=RtAuditCtrl.html

So adding the Audit Control profile would allow our auditor to disable the audit service:

bleonard@os200906:/etc/security$ pfexec rolemod -P "Audit Review,Audit Control" auditor

But wait, does it?

auditor@os200906:~$ svcadm disable auditd
svcadm: svc:/system/auditd:default: Permission denied.

This is actually a bug in that the SMF manifest for auditd defines only an action authorization, but not a value authorization. Without a value authorization, permanent changes to the service cannot be made by the auditor. However, because an action authorization is defined, the service can still be stopped temporily (until the next reboot):

auditor@os200906:~$ svcadm disable -t auditd 

Post a Comment:
  • HTML Syntax: NOT allowed

The Observatory is a blog for users of Oracle Solaris. Tune in here for tips, tricks and more as we explore the Solaris operating system from Oracle.


« July 2016