Description of problem: Certicom ECC(Elliptic curve cryptography) library has some of its data in user home directory, and when there is interaction between the client side certicom lib. located in the user hoem dir, and dogtag certificate system server, 'write' access is denied to certicom data located under the user directory. An example of interaction: Renewing SSL server cert of dogtag certificate system using it's java console. Is there a way to mitigate these kind of access issues where write access to user's home dir. is needed More info: ##################################### [root@nocp1 alias]# sealert -l 20fb0171-35c6-446a-a7eb-dd65394b280d Summary: SELinux is preventing java (pki_ca_t) "write" to ./sbcppri.db (usr_t). Detailed Description: SELinux denied access requested by java. It is not expected that this access is required by java and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./sbcppri.db, restorecon -v './sbcppri.db' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context root:system_r:pki_ca_t Target Context system_u:object_r:usr_t Target Objects ./sbcppri.db [ dir ] Source java Source Path /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre /bin/java Port <Unknown> Host nocp1.foo.bar.com Source RPM Packages java-1.6.0-openjdk-1.6.0.0-1.22.1.9.8.el5_6 Target RPM Packages Policy RPM selinux-policy-2.4.6-316.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name nocp1.foo.bar.com Platform Linux nocp1.foo.bar.com 2.6.18-274.3.1.el5 #1 SMP Fri Aug 26 18:49:02 EDT 2011 x86_64 x86_64 Alert Count 1 First Seen Mon Oct 17 04:28:31 2011 Last Seen Mon Oct 17 04:28:31 2011 Local ID 20fb0171-35c6-446a-a7eb-dd65394b280d Line Numbers Raw Audit Messages host=nocp1.foo.bar.com type=AVC msg=audit(1318850911.600:1029): avc: denied { write } for pid=21671 comm="java" name="sbcppri.db" dev=sdb1 ino=1140509 scontext=root:system_r:pki_ca_t:s0 tcontext=sys tem_u:object_r:usr_t:s0 tclass=dir host=nocp1.foo.bar.com type=SYSCALL msg=audit(1318850911.600:1029): arch=c000003e syscall=2 success=no exit=-13 a0=2aaabc06c7b0 a1=241 a2=180 a3=0 items=0 ppid=21471 pid=21671 auid=0 uid=17 gid=17 euid =17 suid=17 fsuid=17 egid=17 sgid=17 fsgid=17 tty=(none) ses=29 comm="java" exe="/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java" subj=root:system_r:pki_ca_t:s0 key=(null) ##################################### [root@nocp1 conf]# cat /var/log/audit/audit.log | audit2allow -R require { type pki_ca_t; } #============= pki_ca_t ============== files_manage_usr_files(pki_ca_t) files_rw_usr_dirs(pki_ca_t) [root@nocp1 conf]# ##################################### => Location of sbcppri.db ##################################### [root@nocp1 conf]# find / -name *sbcppri.db* /home/user2/.certicom/sbcp/sbcppri.db /usr/share/pki/pkiuser/.certicom/sbcp/sbcppri.db #####################################
Reassigning to cfu. This is not really a selinux problem - as much as a problem of ECC setup. Certicom setup should be standardized so that any required files are located in the appropriate location for selinux to pick them up. i.e. for example in the /var/lib/pki-ca tree. Or alternatively, the right selinux fcontext commands should be documented.
The following is the result of discussion and experiment with Nathan: The following commands will allow ECC servers to startup as well as read/write to certicom token to work, such as the pkiconsole cert renewal procedure mentioned in the report (I've tested on both my CA and DRM ECC instances). # Assuming the certicom is installed under the user pkiuser, whose $HOME # is /usr/share/pki /usr/sbin/semanage fcontext -a -t pki_common_t /usr/share/pki/.certicom\(/.*\)? restorecon -r -v /usr/share/pki/.certicom
The above needs to go into various documentations, including how to setup ECC.
*** Bug 508003 has been marked as a duplicate of this bug. ***
set to MODIFIED for QE to test. Affected document should be updated after successful verification.
(In reply to comment #5) > The following is the result of discussion and experiment with Nathan: > > The following commands will allow ECC servers to startup as well as read/write > to certicom token to work, such as the pkiconsole cert renewal procedure > mentioned in the report (I've tested on both my CA and DRM ECC instances). > > # Assuming the certicom is installed under the user pkiuser, whose $HOME > # is /usr/share/pki > /usr/sbin/semanage fcontext -a -t pki_common_t > /usr/share/pki/.certicom\(/.*\)? > restorecon -r -v /usr/share/pki/.certicom two things: 1. the formatting in comment #5 had an extra carriage return so it looks like two lines for the semanage command. It should read: /usr/sbin/semanage fcontext -a -t pki_common_t /usr/share/pki/.certicom\(/.*\)? restorecon -r -v /usr/share/pki/.certicom 2. if you install a new instance on the same machine (say, another ca instance), then it looks like /usr/share/pki and /user/share/pki/pki-<subsystem> gets overwritten. So you need to reply again: chcon -R -t usr_t /usr/share/pki /usr/sbin/semanage fcontext -a -t pki_common_t /usr/share/pki/.certicom\(/.*\)? restorecon -r -v /usr/share/pki/.certicom
(In reply to comment #9) > (In reply to comment #5) > > The following is the result of discussion and experiment with Nathan: > > > > The following commands will allow ECC servers to startup as well as read/write > > to certicom token to work, such as the pkiconsole cert renewal procedure > > mentioned in the report (I've tested on both my CA and DRM ECC instances). > > > > # Assuming the certicom is installed under the user pkiuser, whose $HOME > > # is /usr/share/pki > > /usr/sbin/semanage fcontext -a -t pki_common_t > > /usr/share/pki/.certicom\(/.*\)? > > restorecon -r -v /usr/share/pki/.certicom > > two things: > 1. the formatting in comment #5 had an extra carriage return so it looks > like two lines for the semanage command. It should read: > /usr/sbin/semanage fcontext -a -t pki_common_t > /usr/share/pki/.certicom\(/.*\)? > restorecon -r -v /usr/share/pki/.certicom Christina, I think you meant there: (while appropriately replacing 'pkiuser3' with whatever user the PKI instance was created with) $ semanage fcontext -a -t pki_common_t /usr/share/pki/pkiuser3/.certicom\(/.*\)? $ restorecon -r -v /usr/share/pki/pkiuser3/.certicom (because there wouldn't be any .certicom directory under the absolute path /usr/share/pki) > > 2. if you install a new instance on the same machine (say, another ca > instance), then it looks like /usr/share/pki and > /user/share/pki/pki-<subsystem> gets overwritten. So you need to reply > again: > chcon -R -t usr_t /usr/share/pki > /usr/sbin/semanage fcontext -a -t pki_common_t > /usr/share/pki/.certicom\(/.*\)? > restorecon -r -v /usr/share/pki/.certicom
Some verification info with SELinux Enforcing: Version Info: #----------------------------------------------------------------------------# [root@nocp5 ~]# rpm -qi pki-ca Name : pki-ca Relocations: (not relocatable) Version : 8.1.1 Vendor: Red Hat, Inc. Release : 1.ecc.el5pki Build Date: Sat 17 Nov 2012 02:56:42 PM EST #----------------------------------------------------------------------------# [root@nocp5 ~]# rpm -qi pki-selinux Name : pki-selinux Relocations: (not relocatable) Version : 8.1.0 Vendor: Red Hat, Inc. Release : 2.ecc.el5pki Build Date: Sat 17 Nov 2012 02:54:49 PM EST Install Date: Sun 18 Nov 2012 02:04:46 PM EST Build Host: payday.dsdev.sjc.redhat.com #----------------------------------------------------------------------------# #----------------------------------------------------------------------------#[root@nocp5 pkiuser2]# getenforce Enforcing #----------------------------------------------------------------------------#[root@nocp5 pkiuser2]# service pki-ca-nov18-nocp5 restart Stopping pki-ca-nov18-nocp5: ..............................[ OK ] Starting pki-ca-nov18-nocp5: Using Java Security Manager Constructing 'pki-ca-nov18-nocp5.policy' Security Policy Starting pki-ca-nov18-nocp5: [ OK ] pki-ca-nov18-nocp5 (pid 11872) is running ... Unsecure Port = http://nocp5.dsdev.sjc.redhat.com:51180/ca/ee/ca Secure Agent Port = https://nocp5.dsdev.sjc.redhat.com:51143/ca/agent/ca Secure EE Port = https://nocp5.dsdev.sjc.redhat.com:51144/ca/ee/ca Secure Admin Port = https://nocp5.dsdev.sjc.redhat.com:51145/ca/services EE Client Auth Port = https://nocp5.dsdev.sjc.redhat.com:51146/ca/eeca/ca PKI Console Port = pkiconsole https://nocp5.dsdev.sjc.redhat.com:51145/ca Tomcat Port = 51101 (for shutdown) PKI Instance Name: pki-ca-nov18-nocp5 PKI Subsystem Type: Root CA (Security Domain) Registered PKI Security Domain Information: ========================================================================== Name: DsdevSjcRedhat Domain-nov18-2012 URL: https://nocp5.dsdev.sjc.redhat.com:51145 ========================================================================== #----------------------------------------------------------------------------# [root@nocp5 pkiuser2]# cat /var/log/audit/audit.log | audit2allow -R [root@nocp5 pkiuser2]# #----------------------------------------------------------------------------# [root@nocp5 pkiuser2]# ls -lZ /usr/share/pki/ drwxr-xr-x root root system_u:object_r:usr_t ca drwxr-xr-x root root system_u:object_r:usr_t ca-ui drwxr-xr-x root root system_u:object_r:usr_t common-ui drwxr-xr-x root root system_u:object_r:usr_t java-tools drwxr-xr-x root root system_u:object_r:usr_t kra drwxr-xr-x root root system_u:object_r:usr_t kra-ui drwxr-xr-x root root system_u:object_r:usr_t md5sum drwxr-xr-x root root system_u:object_r:usr_t ocsp drwxr-xr-x root root system_u:object_r:usr_t ocsp-ui drwxr-xr-x pkiuser1 pkiuser1 system_u:object_r:usr_t pkiuser1 drwxr-xr-x pkiuser2 pkiuser2 system_u:object_r:usr_t pkiuser2 drwxr-xr-x root root system_u:object_r:usr_t ra drwxr-xr-x root root system_u:object_r:usr_t ra-ui drwxr-xr-x root root system_u:object_r:usr_t scripts drwxr-xr-x root root system_u:object_r:usr_t setup drwxr-xr-x root root system_u:object_r:usr_t silent drwxr-xr-x root root system_u:object_r:usr_t templates drwxr-xr-x root root system_u:object_r:usr_t tks drwxr-xr-x root root system_u:object_r:usr_t tks-ui drwxr-xr-x root root system_u:object_r:usr_t tps drwxr-xr-x root root system_u:object_r:usr_t tps-ui [root@nocp5 pkiuser2]# #----------------------------------------------------------------------------# [root@nocp5 pkiuser2]# ls -lZ /home/test/.certicom/ drwxr-x--- test test root:object_r:user_home_t sbcp [root@nocp5 pkiuser2]# #----------------------------------------------------------------------------# [root@nocp5 pkiuser2]# cat /var/log/audit/audit.log | audit2allow -R [root@nocp5 pkiuser2]# #----------------------------------------------------------------------------# It could be noted from the above, with a successful ECC CA( w/ certicom) configuration, restarting the CA doesn't produce any AVCs
Version Info: |------------------------------------------------------------------------------------------------------------------| [root@nocp4 ~]# rpm -qi pki-ca Name : pki-ca Relocations: (not relocatable) Version : 8.1.1 Vendor: Red Hat, Inc. Release : 1.ecc.el5pki Build Date: Sun 13 Jan 2013 02:56:02 PM EST |------------------------------------------------------------------------------------------------------------------| [root@nocp4 ~]# rpm -qi pki-selinux Name : pki-selinux Relocations: (not relocatable) Version : 8.1.0 Vendor: Red Hat, Inc. Release : 2.ecc.el5pki Build Date: Sun 13 Jan 2013 02:54:08 PM EST |------------------------------------------------------------------------------------------------------------------| [root@nocp4 ~]# getenforce Enforcing |------------------------------------------------------------------------------------------------------------------| [root@nocp4 pki]# ls -ldZ pkiuser1 drwx------ pkiuser1 pkiuser1 system_u:object_r:usr_t pkiuser1 [root@nocp4 pki]# ls -lZ pkiuser1/.certicom/ drwxr-x--- pkiuser1 pkiuser1 system_u:object_r:pki_common_t sbcp [root@nocp4 pki]# ls -lRZ pkiuser1/.certicom/ pkiuser1/.certicom/: drwxr-x--- pkiuser1 pkiuser1 system_u:object_r:pki_common_t sbcp pkiuser1/.certicom/sbcp: drwx------ pkiuser1 pkiuser1 system_u:object_r:pki_common_t sbcppri.db drwx------ pkiuser1 pkiuser1 system_u:object_r:pki_common_t sbcppub.db drwx------ pkiuser1 pkiuser1 system_u:object_r:pki_common_t sbcpso.db drwx------ pkiuser1 pkiuser1 system_u:object_r:pki_common_t sbcpuser.db pkiuser1/.certicom/sbcp/sbcppri.db: -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x00 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x01000000 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x02000000 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x03000000 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x04000000 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x05000000 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x06000000 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x07000000 pkiuser1/.certicom/sbcp/sbcppub.db: -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x00 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x01000000 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x02000000 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x03000000 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x04000000 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x05000000 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x06000000 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x07000000 pkiuser1/.certicom/sbcp/sbcpso.db: -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x00 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x01000000 pkiuser1/.certicom/sbcp/sbcpuser.db: -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x00 -rw------- pkiuser1 pkiuser1 system_u:object_r:pki_common_t x01000000 [root@nocp4 pki]# |------------------------------------------------------------------------------------------------------------------| [root@nocp4 ~]# service pki-ca-feb8-inst1-nocp4 restart Stopping pki-ca-feb8-inst1-nocp4: ...............................[ OK ] Starting pki-ca-feb8-inst1-nocp4: Using Java Security Manager Constructing 'pki-ca-feb8-inst1-nocp4.policy' Security Policy Starting pki-ca-feb8-inst1-nocp4: [ OK ] pki-ca-feb8-inst1-nocp4 (pid 19410) is running ... Unsecure Port = http://nocp4.dsdev.sjc.redhat.com:9180/ca/ee/ca Secure Agent Port = https://nocp4.dsdev.sjc.redhat.com:9443/ca/agent/ca Secure EE Port = https://nocp4.dsdev.sjc.redhat.com:9444/ca/ee/ca Secure Admin Port = https://nocp4.dsdev.sjc.redhat.com:9445/ca/services EE Client Auth Port = https://nocp4.dsdev.sjc.redhat.com:9446/ca/eeca/ca PKI Console Port = pkiconsole https://nocp4.dsdev.sjc.redhat.com:9445/ca Tomcat Port = 9701 (for shutdown) PKI Instance Name: pki-ca-feb8-inst1-nocp4 PKI Subsystem Type: Root CA (Security Domain) Registered PKI Security Domain Information: ========================================================================== Name: pki-ca-ecc-08022013-1 URL: https://nocp4.dsdev.sjc.redhat.com:9445 ========================================================================== |------------------------------------------------------------------------------------------------------------------| There were no selinux denial messages even while trying to add a new SSL Certificate through java console.