By Brian Leonard on Jun 23, 2010
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).
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.
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 Password: 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 Password: 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 All
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 return,success,0 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 return,success,0 ...
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 solaris.audit.read,solaris.device.cdrw,solaris.profmgr.read,...
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