Bug 797578

This looks like /tmp has a mislabeled on it.

restorecon -R -v /tmp

Daniel, that sounds reasonable, as I had mounted /tmp as tmpfs as is suggested for taking traffic off of the SSD drive.  I'll give your suggestion a try.

Thanks, Stan

How did you mount it?

I added this line to my /etc/fstab:

none  /tmp  tmpfs   defaults  0 0

That looks fine. 

tmpfs                             /tmp                    tmpfs   defaults        0 0

is what I use.

What does this output?

ls -lZd /tmp

"ls -lZd /tmp" gives the following output:

drwxrwxrwt. root root system_u:object_r:tmp_t:s0       /tmp

(The word "/tmp" is colored green by the Terminal program.)

This is after running the "restorecon" command you had suggested above, and I'm pretty sure I rebooted after that.

Well the restorecon would not have survived the reboot, so I am not sure what happened but you have the right label now, reopen if this happens again.

Daniel, the alert seems to occur reliably during the weekly log file rotation.

Here are the associated lines from /var/log/audit/audit.log, separated by a blank line that I've added to improve readability.  It seems to be similar to that in the original report.

I can set up whatever info gathering you'd like to catch this during the next log file rotation.

type=AVC msg=audit(1330859821.454:2623): avc:  denied  { getattr } for  pid=5291 comm="chrony-helper" name="/" dev=tmpfs ino=11589 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem

type=SYSCALL msg=audit(1330859821.454:2623): arch=40000003 syscall=99 success=no exit=-13 a0=8101dbe a1=bfc26270 a2=41e35ff4 a3=ffffffc8 items=0 ppid=5285 pid=5291 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=365 comm="chrony-helper" exe="/bin/bash" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)

Could you try to turn on full auditing

# auditctl -w /etc/shadow -p w

Try to recreate AVC. Then execute

# ausearch -m avc -ts recent

Thank you.

Miroslav, I've done "auditctl -w /etc/shadow -p w" on the affected machine, in anticipation of it failing again Saturday night.

However, could you please verify that the file to watch should be /etc/shadow as in your comment, instead of the /tmp that appears in the alert message?

Yes, this will show me a full path also in AVC msg.

Stan.

http://danwalsh.livejournal.com/34903.html

Daniel, thanks for the info.  I'm looking forward to the results.

If you can tell me how to have the chrony log files rotated nightly instead of weekly, then this testing could proceed a bit faster.  Would I just add a line containing "daily" into this data found in /etc/logrotate.d/chrony?

/var/log/chrony/*.log {
    missingok
    nocreate
    sharedscripts
    postrotate
        /usr/libexec/chrony-helper command cyclelogs > /dev/null 2>&1 || true
    endscript
}

changing it perhaps to

/var/log/chrony/*.log {
    daily
    missingok
    nocreate
    sharedscripts
    postrotate
        /usr/libexec/chrony-helper command cyclelogs > /dev/null 2>&1 || true
    endscript
}

OK, the event occurred again as expected, and here is the output of "ausearch -m avc -ts yesterday":
----
time->Sun Mar 18 03:10:01 2012
type=PATH msg=audit(1332065401.641:2887): item=0 name="/tmp" inode=11252 dev=00:22 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmp_t:s0
type=CWD msg=audit(1332065401.641:2887):  cwd="/"
type=SYSCALL msg=audit(1332065401.641:2887): arch=40000003 syscall=99 success=no exit=-13 a0=8101dbe a1=bfff9460 a2=41e35ff4 a3=ffffffc8 items=1 ppid=6072 pid=6080 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=398 comm="chrony-helper" exe="/bin/bash" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1332065401.641:2887): avc:  denied  { getattr } for  pid=6080 comm="chrony-helper" name="/" dev=tmpfs ino=11252 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.