(created from Bug 790563) Description of problem: Broker with SSL produces Selinux AVC during service start - only on RHEL6. Enable SSL in qpidd broker: # yum install -y -q qpid-cpp-server qpid-tools nss-tools ecode=0 # echo password > /var/lib/qpidd/passwordfile ecode=0 # chown qpidd:qpidd /var/lib/qpidd/passwordfile ecode=0 # chmod 600 /var/lib/qpidd/passwordfile ecode=0 # cd /var/lib/qpidd ecode=0 # sudo -u qpidd certutil -N -d . -f passwordfile ecode=0 # sudo -u qpidd certutil -S -d . -f passwordfile -n nickname -s "CN=nickname" -t "CT,," -x -z /usr/bin/certutil Generating key. This may take a few moments... ecode=0 # grep --invert-match ^# /etc/qpidd.conf cluster-mechanism=ANONYMOUS auth=yes ssl-cert-password-file=/var/lib/qpidd/passwordfile ssl-cert-db=/var/lib/qpidd ssl-cert-name=nickname ecode=0 # yum install -y -q qpid-cpp-server-ssl ecode=0 # service qpidd restart Stopping Qpid AMQP daemon: [FAILED] Starting Qpid AMQP daemon: [ OK ] ecode=0 # tail /var/log/messages | grep qpidd | cut --delimiter=']' --fields=2 : 2012-02-15 09:44:55 notice Listening on TCP port 5672 : 2012-02-15 09:44:55 notice Listening for SSL connections on TCP port 5671 : 2012-02-15 09:44:55 notice Broker running ecode=0 Verify /var/log/audit/audit.log for AVC messages: type=AVC msg=audit(1329299160.002:19706): avc: denied { read } for pid=1509 comm="qpidd" name="tmp" dev=vda1 ino=128028 scontext=unconfined_u:system_r:qpidd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir Try to analyze this: /var/log/messages: setroubleshoot: SELinux is preventing qpidd from read access on the directory tmp. For complete SELinux messages. run sealert -l c8bb31c9-6a8e-430c-89f4-2a810ca5c9c4 # sealert -l c8bb31c9-6a8e-430c-89f4-2a810ca5c9c4 SELinux is preventing qpidd from read access on the directory tmp. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that qpidd should be allowed read access on the tmp directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep qpidd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Look at /tmp directory: # ls -ldZ /tmp drwxrwxrwt. root root system_u:object_r:tmp_t:s0 /tmp Version-Release number of selected component (if applicable): qpid-cpp-server-ssl-0.12-6.el6.x86_64 qpid-cpp-server-0.12-6.el6.x86_64 qpid-cpp-server-ssl-0.14-6.el6.x86_64 qpid-cpp-server-0.14-6.el6.x86_64 selinux-policy-3.7.19-126.el6_2.6.noarch selinux-policy-targeted-3.7.19-126.el6_2.6.noarch How reproducible: 100% Steps to Reproduce: 1. Enable SSL in broker 2. service qpidd restart 3. New AVC present 4. Disable SSL in broker 5. service qpidd restart 6. No new AVC Actual results: broker with SSL produce AVC during service start Expected results: No AVC messages. Additional info:
Created attachment 565314 [details] Issue reproducer Still pending on last RHEL6.3-20120222.n.0 with selinux-policy-3.7.19-137.el6. We need to doublecheck whether reading from tmp is intentional before raising selinux-policy defect duplicate.
Any reason for this listing the contents of /tmp? Is it looking for kerberos files?
Ted, do you have any insight into why SSL would be reading from /tmp? Is this normal behavior?
Kim and I did some investigation and found the following: In cpp/src/qpid/sys/ssl/util.cpp:111 we see the following: if (server) { //use defaults for all args, TODO: may want to make this configurable SSL_ConfigServerSessionIDCache(0, 0, 0, 0); } The last argument in this call is the directory path for the cache. Its default value is "/tmp". We should consider using the configure script to determine a better place to put this cache and pass that value through to this call.
Yes, this is caused by SSL. Are you getting more AVC msgs with $ setenforce 0
Retested once more on: RHEL6.3-20120222.n.0 i686/x86_64/s390x/ppc64 (selinux-policy-3.7.19-137.el6) RHEL6.2.z i686/x86_64 (selinux-policy-3.7.19-126.el6_2.6) all with just one avc type appearing in enforcing / permissive: type=AVC msg=audit(_T_): avc: denied { read } for pid=_P_ comm="qpidd" name="tmp" dev=sda1 ino=_I_ scontext=unconfined_u:system_r:qpidd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir I'm going to clone this defect for selinux-policy for RHEL 6.2.Z and RHEL6.3.0.
I don't think that SELinux policy should be changed for this; my view is that the broker should be setting aside a location within the directories it already has permissions for (such as /var/qpid) for SSL to set up its working files. I believe that this was the intent of Ted's comment #7 above.
(In reply to comment #10) > I don't think that SELinux policy should be changed for this; my view is that > the broker should be setting aside a location within the directories it already > has permissions for (such as /var/qpid) for SSL to set up its working files. I > believe that this was the intent of Ted's comment #7 above. Thanks for clarification Kim. I'm going to throw the clone away.
Created attachment 566952 [details] Change to qpidd as per comment #7 This patch will do what is asked in comment #7. However I suspect this is not going to solve the actual issue. I can't actually see the server session cache being used in simple usage. Also via strace I still see a stat of /tmp (along with /usrtmp and /var/tmp). It looks to me like this is actually from a different piece of NSS, namely the sqlite component. I'm not sure what purpose that serves but the code is: static int getTempname(int nBuf, char *zBuf){ static const char *azDirs[] = { 0, 0, "/var/tmp", "/usr/tmp", "/tmp", ".", }; //some other stuff in here for(i=0; i<sizeof(azDirs)/sizeof(azDirs[0]); i++){ if( azDirs[i]==0 ) continue; if( stat(azDirs[i], &buf) ) continue; if( !S_ISDIR(buf.st_mode) ) continue; if( access(azDirs[i], 07) ) continue; zDir = azDirs[i]; break; } which looks suspiciously like what I am seeing from strace. This doesn't seem configurable at this level. I'm not exactly sure why this code is called or what its actually doing. It seems like it is perhaps part of the reading of the cert dbs(?), though these are located elsewhere.
Actully re comment #12 above, it looks even more likely that this is part of the unix_rand.c code for RNG_SystemInfoForRNG: static const char * const files[] = { "/etc/passwd", "/etc/utmp", "/tmp", "/var/tmp", "/usr/tmp", 0 }; with a stat() being called on each of these as part of: /* pass other files through */ for (cp = files; *cp; cp++) RNG_FileForRNG(*cp); From strace I see: stat64("/dev/urandom", {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 fstat64(11, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 stat64("/etc/passwd", {st_mode=S_IFREG|0644, st_size=2169, ...}) = 0 fstat64(11, {st_mode=S_IFREG|0644, st_size=2169, ...}) = 0 stat64("/etc/utmp", 0xbfd212fc) = -1 ENOENT (No such file or directory) stat64("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=28672, ...}) = 0 fstat64(11, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=28672, ...}) = 0 stat64("/var/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0 fstat64(11, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0 stat64("/usr/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0 fstat64(11, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0 which is an exact match for the order listed here. So this is reading temp files as a way of generating random seed data or something? Again this doesn't seem to be configurable at this level at least...
We will need to add files_list_tmp(qpidd_t)
*** This bug has been marked as a duplicate of bug 798580 ***