Bug 431588

This looks like yum-cron writes a log file in /tmp and redirects stdout/stderr
to this file.  SELinux is preventing this, but nothing bad is happening.

A cron job should not be writing anything to /tmp since this is a place where
users can hack around.  This could be dangerous.  This log file should be
written to /var/log. Or better yet /var/log/yum-cron.

This will not fix the SELinux messages but would give us a better chance of
writing good policy

Re-assigning to yum-cron to get the yum-cron maintainer's input.

yum-cron captures yum's output to a temp file for later mailing, with something
like:

YUMTMP=$(mktemp /tmp/yum-cron.XXXXXX)
yum > $YUMTMP 2>&1
if [ ! -z "$MAILTO" ]; then
# if MAILTO is set, use mail command (ie better than standard mail with cron output)
  [ -s "$YUMTMP" ] && mail -s "System update: $SYSTEMNAME" $MAILTO < $YUMTMP
else
# default behavior is to use cron's internal mailing of output from cron-script
  cat $YUMTMP
fi
rm -f $YUMTMP

So, I suppose:

YUMTMP=$(mktemp /var/log/yum-cron.XXXXXX)

would work, though we don't normally associate /var/log with temporary files.

Comments?

Will happily change the script to coexist with standards, although I'm frankly
astonished that /tmp has become verboten for use with constructing temporary
files.  Is /var/tmp more appropriate?  Is there a variation on the mktemp call
which constructs a more secure scratch file?  What if the file creation mask was
set more restrictively so that people couldn't peek at it?

Surely yum-cron isn't the only system process writing to /tmp.  A quick check on
my F-8 machine shows the X server making liberal use of this directory, for
example.  Although the cron-driven logwatch package is the most comparable, and
it writes to /var/cache/logwatch

Daniel, please direct me to the place selinux wants tmpfiles to go, and I'll put
them there.

Well my proplem is system (root) programs creating file in a directory where
users have full control.  

It is my own personal crusade.

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

/var/run is a location that is often used for storage of System Temporary files.
I also see this as a log file which could be stored in /var/log.
yum also uses /var/cache for storage of cached file that are considered somewhat
temporary.

Any directory that an non privileged user can write to is a bad idea.

Since the file doesn't survive the process writing it, no one can read it later,
so it's not a log file.  It also doesn't need to survive a reboot, so I'll move
it to /var/run.

Okay, I changed yum-cron locally to use /var/run.  Now I get:

Feb  8 05:27:09 kolea kernel: audit(1202473629.188:29): avc:  denied  { write }
for  pid=6805 comm="ldconfig" path="/var/run/yum-cron.QJ3712" dev=dm-2 ino=28743
scontext=user_u:system_r:ldconfig_t:s0 tcontext=user_u:object_r:var_run_t:s0
tclass=file

Dan - can you write policy for that?

This problem exists in Fedora 8 as well.

Maybe a solution would be to use "yum-updatesd --oneshot"? See
https://bugzilla.redhat.com/show_bug.cgi?id=325531 for details.

Policy Fixed in  selinux-policy-3.0.8-88.fc8

Thanks Dan.  The matching yum-cron change is put together and (pending
additional testing by the bug reporters) will get pushed to update hopefully by
the weekend.

yum-cron-0.8-1.fc7 has been submitted as an update for Fedora 7

yum-cron-0.8-1.fc8 has been submitted as an update for Fedora 8

yum-cron-0.8-1.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update yum-cron'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-1916

yum-cron-0.8-1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

yum-cron-0.8-1.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Dan - now I'm seeing:

Apr  1 04:37:35 shavano kernel: audit(1207046255.613:6): avc:  denied  { write }
for  pid=25472 comm="tzdata-update" path="/var/run/yum-cron.h22569" dev=dm-1
ino=32937 scontext=system_u:system_r:tzdata_t:s0-s0:c0.c1023
tcontext=system_u:object_r:var_run_t:s0 tclass=file

Looks like different scontext?  Can we make this scontext agnostic?

Well it is pretty hard to for now.  We could allow read/write over 


We would need something along the lines of

allow domain rpm_log_t:file { read write };
or
dontaudit domain rpm_log_t:file { read write };

ANd then label it rpm_log_t.

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

(In reply to comment #17)
> Well it is pretty hard to for now.  We could allow read/write over 
> 
> We would need something along the lines of
> 
> allow domain rpm_log_t:file { read write };
> or
> dontaudit domain rpm_log_t:file { read write };
> 
> ANd then label it rpm_log_t.

Whatever works.

The problem still exists in Fedora 8, so maybe someone can switch the version
field to Fedora 8?

Updated to F-8.

If you add a "cat" pipe does it work without AVC messages?

# and all that just to do this:
{
  /usr/bin/yum $YUM_PARAMETER -e ${ERROR_LEVEL:-0} -d ${DEBUG_LEVEL:-0} clean
packages
} | cat > $YUMTMP 2>&1

This will cause the confined apps to just write to a pipe rather then a labeled
files and should be allowed.

(In reply to comment #22)
> If you add a "cat" pipe does it work without AVC messages?

I'll try it out and report back.

(In reply to comment #22)
> If you add a "cat" pipe does it work without AVC messages?

It appears to remove the avc messages.

So, should yum.cron use the cat or should something else be done.  Seems like a kludge.

How about changing it to an append and then we could allow it.  Allowing any confined domain to write to rpm.log could cover up the fact that a confined domain installed a package.

To be clear what you'd like done before I commit changes:

1) Change the output to the temp log file in /var/run/yum-cron.* to a cat pipe kludge as in comment #22

2) Make it an append ">>" rather than a straight ">" ?  yum-cron will still have to create the file for it to be appended, are there any problems with the initial creation?

I would like 2 done.

Not 1.  1 is a work around.

If you use append, I can give several confined domains the ability to append to the rpm log files, without giving them the ability to write(truncate) them.

diff -up /etc/cron.daily/yum.cron~ /etc/cron.daily/yum.cron
--- /etc/cron.daily/yum.cron~	2008-03-13 15:05:18.000000000 -0400
+++ /etc/cron.daily/yum.cron	2008-11-18 12:06:24.000000000 -0500
@@ -34,6 +34,8 @@ if [ "$DOWNLOAD_ONLY" == "yes" ]; then
   CHECK_ONLY=yes
 fi
 
+touch $YUMTMP 
+restorecon $YUMTMP
 # Then check for updates and/or do them, as configured
 {
   if [ "$CHECK_ONLY" == "yes" ]; then
@@ -63,7 +65,7 @@ fi
     /usr/bin/yum $YUM_PARAMETER -R $RANDOMWAIT -e ${ERROR_LEVEL:-0} -d ${DEBUG_LEVEL:-0} -y update yum
     /usr/bin/yum $YUM_PARAMETER -e ${ERROR_LEVEL:-0} -d ${DEBUG_LEVEL:-0} -y shell /etc/yum/yum-daily.yum
   fi
-} > $YUMTMP 2>&1
+} >> $YUMTMP 2>&1
 
 if [ ! -z "$MAILTO" ]; then 
 # if MAILTO is set, use mail command (ie better than standard mail with cron output) 
[root@localhost tmp]# gendiff /etc/cron.daily \~ > /tmp/t

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Alec, there seems to be a suggested solution by Dan Walsh in the comment 28.

Sorry for the delay, professoring strongly limits my in-semester open source work. 

Implemented Dan's simply append patch from comment #28 in a new yum-cron-0.8.3-1, in koji's F11 branch.  Could you please give that a whirl, if you like it I'll push it to testing for older branches.

yum-cron-0.8.3-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/yum-cron-0.8.3-1.fc9

yum-cron-0.8.3-1.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/yum-cron-0.8.3-1.fc8

yum-cron-0.8.3-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/yum-cron-0.8.3-1.fc10

yum-cron-0.8.3-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update yum-cron'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11863

yum-cron-0.8.3-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update yum-cron'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-11888

yum-cron-0.8.3-1.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update yum-cron'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-11890

yum-cron-0.8.3-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

yum-cron-0.8.3-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.