Bug 746701

Summary:	selinux denials for application data located under user home directory in ECC certicom setup
Product:	[Retired] Dogtag Certificate System	Reporter:	Kashyap Chamarthy <kchamart>
Component:	SELinux	Assignee:	Christina Fu <cfu>
Status:	CLOSED NEXTRELEASE	QA Contact:	Chandrasekar Kannan <ckannan>
Severity:	medium	Docs Contact:
Priority:	high
Version:	9.0	CC:	alee, benl, cfu, dlackey, dominick.grift, dpal, dwalsh, enewland, jgalipea, jmagne, mgrepl, mharmsen, mniranja, nkinder
Target Milestone:	9.0
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	746756 (view as bug list)		Environment:
Last Closed:	2014-08-29 01:33:18 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	703312, 746756, 754280

Description Kashyap Chamarthy 2011-10-17 14:55:20 UTC

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
#####################################

Comment 1 Ade Lee 2011-10-17 15:19:42 UTC

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.

Comment 5 Christina Fu 2012-03-30 23:38:39 UTC

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

Comment 6 Christina Fu 2012-03-30 23:40:43 UTC

The above needs to go into various documentations, including how to setup ECC.

Comment 7 Christina Fu 2012-03-30 23:41:09 UTC

*** Bug 508003 has been marked as a duplicate of this bug. ***

Comment 8 Christina Fu 2012-03-30 23:55:01 UTC

set to MODIFIED for QE to test.  Affected document should be updated after successful verification.

Comment 9 Christina Fu 2012-04-09 21:08:22 UTC

(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

Comment 11 Kashyap Chamarthy 2012-12-04 14:56:09 UTC

(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

Comment 12 Kashyap Chamarthy 2012-12-05 20:55:26 UTC

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

Comment 13 Niranjan Mallapadi Raghavender 2013-02-20 14:49:01 UTC

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.