This is a discussion on Rights Profiles - Solaris Rss ; 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 ...
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.h tmlWe 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.htmlWhen 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.htmlWe 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_attrand as the name implies, lists the commands that users or rolesassigned the rights profile are allowed to run. In addition, thecommands can be specified to run with alternative user ids and/orprivileges. For example, if we look at the Audit Review records in exec_attr:
Audit Review:suser:cmd:::/usr/sbin/auditreduce:euid=0Audit Review:suser:cmd:::/usr/sbin/auditstat:euid=0Audit Review:suser:cmd:::/usr/sbin/praudit:euid=0Users 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 auditor80 blocksbleonard@os200906:~$ pfexec passwd auditorNew Password: Re-enter new Password: passwd: password successfully changed for auditorAnd 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 blocksbleonard@os200906:~$ pfexec passwd tstarkNew Password: Re-enter new Password: passwd: password successfully changed for tstarkNow, if tstark logs into the machine and tries to review the audit trail:
bleonard@os200906:~$ ssh -X tstark@os200906Password: Last login: Tue Jun 22 10:29:13 2010 from os200906Sun Microsystems Inc. SunOS 5.11 snv_111b November 2008tstark@os200906:~$ su - auditorPassword: 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:~$ profilesBasic Solaris UserAllSo now let's add the Audit Review profile to the auditor role and try again:
bleonard@os200906:~$ pfexec rolemod -P "Audit Review" auditorAnd 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:00text,booting kernelheader,69,2,login - local,,localhost,2010-06-21 16:27:25.183 -04:00subject,bleonard,bleonard,staff,bleonard,staf f,477,3112795690,0 0 localhostreturn,success,0header,69,2,login - local,,localhost,2010-06-21 16:28:24.881 -04:00subject,bleonard,bleonard,staff,bleonard,staf f,615,3530634311,0 0 localhostreturn,success,0...Let's try to do something else, like disable the audit:
auditor@os200906:~$ svcadm disable auditdsvcadm: 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 authorizationgeneral/action_authorization astring solaris.audit.configAnd then look at the auditor's authorizations, you'll see that we have the solaris.audit.read, but not solaris.audit.config:
auditor@os200906:~$ authssolaris.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,sol aris.admin.logsvc.read;help=RtAuditCtrl.htmlSo 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" auditorBut wait, does it?
auditor@os200906:~$ svcadm disable auditdsvcadm: 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 auditdRead More about [Rights Profiles...