Some notes

I found this document in Sun Blueprint. It is created by Glen Brunette, one of Sun guys that i admired.
There's 2 things in the document that did not point out, one of them is giving permission to /var/audit/* files, and the other one is stopping cryptoadm by non-root user bring the cryptosvc to maintenance state when try to bring up.

First 'problem' details:
Assuming i am user weehing, and i was assigned "Audit Review" profile. Now i would like to audit user oracle activity, this is the same steps as illustrated in Glen's doc.

[weehing@pw250 ~]$ auditreduce -m AUE_su -r oracle | praudit -s | more
auditreduce: couldn't open:
/etc/security/audit/localhost/files/20080723041356.20080723041357.pw250: Permission denied
auditreduce: couldn't open:
/etc/security/audit/localhost/files/20080723041357.not_terminated.pw250: Permission denied
file,1970-01-01 07:30:00.000 +07:30,
file,2008-07-23 13:55:50.000 +08:00,

[weehing@pw250 ~]$ ls -l /etc/security/audit/localhost/files/*
-rw------- 1 root root 70 Jul 23 12:13 /etc/security/audit/localhost/files/20080723041356.20080723041357.pw250
-rw------- 1 root root 21080 Jul 23 13:58 /etc/security/audit/localhost/files/20080723041357.not_terminated.pw250


To allow weehing to audit oracle's activity, read permission would have to be given to weehing. This can be solved by a change in audit binary file permission, but this can be be another concern.


Second 'problem':

[weehing@pw250 ~]$ roles
roleA
[weehing@pw250 ~]$ profiles -l

Audit Review:
/usr/sbin/auditreduce euid=0
/usr/sbin/auditstat euid=0
/usr/sbin/praudit euid=0
All:
*
[weehing@pw250 ~]$ auths
solaris.audit.read,solaris.device.cdrw,solaris.profmgr.read,solaris.jobs.users,solaris.mail.mailq,solaris.admin.usermgr.read,solaris.admin.logsvc.read,solaris.admin.fsmgr.read,solaris.admin.serialmgr.read,solaris.admin.diskmgr.read,solaris.admin.procmgr.user,solaris.compsys.read,solaris.admin.printer.read,solaris.admin.prodreg.read,solaris.admin.dcmgr.read,solaris.snmp.read,solaris.project.read,solaris.admin.patchmgr.read,solaris.network.hosts.read,solaris.admin.volmgr.read
[weehing@pw250 ~]$ svcs cryptosvc
STATE STIME FMRI
online 17:19:30 svc:/system/cryptosvc:default
[weehing@pw250 ~]$
[weehing@pw250 ~]$ digest -a sha1 /etc/hosts
ee4ef007673a3090a4cc00bdb125ec8c146cf7e4
[weehing@pw250 ~]$
[weehing@pw250 ~]$ cryptoadm stop
cryptoadm: failed to stop cryptographic framework daemon - Not owner.
[weehing@pw250 ~]$ su roles
su: Unknown id: roles
[weehing@pw250 ~]$ su roleA
Password:
$ svcs cryptosvc
STATE STIME FMRI
online 17:19:30 svc:/system/cryptosvc:default
$ cryptoadm stop
$ svcs cryptosvc
STATE STIME FMRI
maintenance 17:34:54 svc:/system/cryptosvc:default
$ digest -a sha1 /etc/hosts
digest: failed to initialize PKCS #11 framework: CKR_GENERAL_ERROR
$ cryptoadm start
$ digest -a sha1 /etc/hosts
ee4ef007673a3090a4cc00bdb125ec8c146cf7e4
$ svcs cryptosvc
STATE STIME FMRI
maintenance 17:34:54 svc:/system/cryptosvc:default <---all gone here until here, though this is not really a issue as digest command still works.
$ svcadm clear svc:/system/cryptosvc:default
svcadm: svc:/system/cryptosvc:default: Permission denied.

How to bring the cryptosvc back to online state??

[root@pw250 patches]$ cryptoadm stop
[root@pw250 patches]$ svcs cryptosvc
STATE STIME FMRI
maintenance 17:34:54 svc:/system/cryptosvc:default
[root@pw250 patches]$ svcadm clear svc:/system/cryptosvc:default
[root@pw250 patches]$ svcs cryptosvc
STATE STIME FMRI
online 17:39:25 svc:/system/cryptosvc:default

Well, this is nothing much, but just some findings for reader who follows Glen's doc and might hit the same things like me.