Bug 790759

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