Since the upgrade to F9, logwatch can no longer user courier for sending out email. This is seen in the logs: May 27 04:36:57 volvo kernel: type=1400 audit(1211855817.046:19): avc: denied { setuid } for pid=26346 comm="sendmail" capability=7 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tclass=capability May 27 04:36:57 volvo kernel: type=1400 audit(1211855817.051:20): avc: denied { setuid } for pid=26347 comm="submit" capability=7 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tclass=capability
What is courier? What is the sendmail command labeled? Logwatch is supposed to transition to system_mail_t when executing a program labeled sendmail_exec_t.
Heh, sorry. :) Courier is another MTA (http://www.courier-mta.org). It is labeled bin_t though: -r-s--x--x root daemon system_u:object_r:bin_t:s0 /usr/lib/courier/bin/sendmail
If you chcon -t sendmail_exec_t /usr/lib/courier/bin/sendmail Does it solve your problem?
I can test. Do you have some way of running logwatch under the correct context? sudo and newrole all refuse to change to system_r:logwatch_t (probably because I'm unconfined_t).
Not easily you could label a script initrc_exec_t and run logwatch in it, this should transition properly. You can put the system in permissive mode and use runcon also.
That solved the setuid problems. But there is some problems writing stuff to the mail spool: type=1400 audit(1211976679.662:22): avc: denied { write } for pid=8273 comm="submit" name="121197" dev=dm-0 ino=49190 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir type=1400 audit(1211976679.663:23): avc: denied { add_name } for pid=8273 comm="submit" name="1211976679.8273.smtp.fordonsservice.se" scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir type=1400 audit(1211976679.663:24): avc: denied { create } for pid=8273 comm="submit" name="1211976679.8273.smtp.fordonsservice.se" scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_spool_t:s0 tclass=file type=1400 audit(1211976679.663:25): avc: denied { append } for pid=8273 comm="submit" name="1211976679.8273.smtp.fordonsservice.se" dev=dm-0 ino=49191 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_spool_t:s0 tclass=file type=1400 audit(1211976679.663:26): avc: denied { write } for pid=8273 comm="submit" name="D49191" dev=dm-0 ino=49192 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_spool_t:s0 tclass=file type=1400 audit(1211976679.679:27): avc: denied { remove_name } for pid=8273 comm="submit" name="1211976679.8273.smtp.fordonsservice.se" dev=dm-0 ino=49191 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir type=1400 audit(1211976679.679:28): avc: denied { rename } for pid=8273 comm="submit" name="1211976679.8273.smtp.fordonsservice.se" dev=dm-0 ino=49191 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_spool_t:s0 tclass=file type=1400 audit(1211976679.679:29): avc: denied { write } for pid=8273 comm="submit" name="trigger" dev=dm-0 ino=49183 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_spool_t:s0 tclass=fifo_file I guess the problem is that the files are tagged var_spool_t instead of mail_spool_t. So after a chcon -R -t mail_spool_t /var/spool/courier, I get this: type=1400 audit(1211977109.784:30): avc: denied { transition } for pid=8580 comm="runcon" path="/usr/share/logwatch/scripts/logwatch.pl" dev=dm-0 ino=295881 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tclass=process type=1400 audit(1211977110.189:31): avc: denied { read } for pid=8580 comm="0logwatch" name="spool" dev=dm-0 ino=41412 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir type=1400 audit(1211977116.107:32): avc: denied { write } for pid=8707 comm="submit" name="trigger" dev=dm-0 ino=49183 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mail_spool_t:s0 tclass=fifo_file The first and last seem to be caused by my unconfined role, but I'm not sure what's going on in the second one. I doubt it's courier though as the comm is "0logwatch".
Hello, I'm using sendmail (stock configuration provided by Fedora plus a /root/.forward file containing my e-mail adddress) and I still see that bug since upgrading from F8 to F9. Logs don't arrive via e-mail anymore (they used to). Regards, Răzvan
So what's the next step here? Is it possible to get courier's paths added to the policy?
Try selinux-policy-3.3.1-60 It has +/usr/lib(64)?/courier/sendmail -- gen_context(system_u:object_r:courier_exec_t,s0) +/var/spool/courier(/.*)? gen_context(system_u:object_r:mail_spool_t,s0) -bash-3.2$
Close, but not quite. You forgot a bin there: /usr/lib(64)?/courier/bin/sendmail -- gen_context(system_u:object_r:courier_exec_t,s0) Still needs a bit more though, as now neither logwatch nor cron are able to fire off any mail: May 31 10:25:02 fiat kernel: type=1400 audit(1212222302.159:44): avc: denied { read } for pid=15942 comm="0logwatch" name="root" dev=dm-0 ino=229377 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir May 31 10:25:02 fiat kernel: type=1400 audit(1212222302.166:45): avc: denied { read } for pid=15942 comm="0logwatch" name="root" dev=dm-0 ino=229377 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir May 31 10:25:02 fiat kernel: type=1400 audit(1212222302.167:46): avc: denied { read } for pid=15942 comm="0logwatch" name="root" dev=dm-0 ino=229377 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir May 31 10:25:02 fiat kernel: type=1400 audit(1212222302.172:47): avc: denied { read } for pid=15942 comm="0logwatch" name="root" dev=dm-0 ino=229377 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir May 31 10:25:02 fiat kernel: type=1400 audit(1212222302.173:48): avc: denied { read } for pid=15942 comm="0logwatch" name="root" dev=dm-0 ino=229377 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir May 31 10:25:02 fiat kernel: type=1400 audit(1212222302.178:49): avc: denied { read } for pid=15942 comm="0logwatch" name="root" dev=dm-0 ino=229377 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir May 31 10:25:02 fiat kernel: type=1400 audit(1212222302.184:50): avc: denied { read } for pid=15942 comm="0logwatch" name="root" dev=dm-0 ino=229377 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir May 31 10:25:07 fiat kernel: printk: 87 messages suppressed. May 31 10:25:07 fiat kernel: type=1400 audit(1212222307.675:80): avc: denied { search } for pid=16308 comm="submit" name="courier" dev=dm-0 ino=173523 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_etc_t:s0 tclass=dir
Did some more testing and enabled one thing after the other. Finally I composed this rule set to get courier running: allow system_mail_t courier_etc_t:dir search; allow system_mail_t courier_etc_t:file { read lock getattr }; allow system_mail_t mail_spool_t:dir create; allow system_mail_t mail_spool_t:fifo_file write; The first two are for courier to read the alias configuration. The third is for it to put the mail in the queue, and the third is to give courierd a kick to notice the new mail. The log messages used to compose the rules: May 31 10:25:07 fiat kernel: type=1400 audit(1212222307.675:80): avc: denied { search } for pid=16308 comm="submit" name="courier" dev=dm-0 ino=173523 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_etc_t:s0 tclass=dir type=1400 audit(1212223207.726:124): avc: denied { read } for pid=16749 comm="submit" name="enablefiltering" dev=dm-0 ino=173536 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_etc_t:s0 tclass=file type=1400 audit(1212223808.013:166): avc: denied { getattr } for pid=17148 comm="submit" path="/etc/courier/enablefiltering" dev=dm-0 ino=173536 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_etc_t:s0 tclass=file type=1400 audit(1212224287.769:205): avc: denied { lock } for pid=17542 comm="submit" path="/etc/courier/aliases.dat" dev=dm-0 ino=172872 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_etc_t:s0 tclass=file type=1400 audit(1212224647.406:240): avc: denied { create } for pid=17947 comm="submitmkdir" name="121222" scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir May 31 11:08:07 fiat kernel: type=1400 audit(1212224887.629:311): avc: denied { write } for pid=18485 comm="submit" name="trigger" dev=dm-0 ino=49183 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mail_spool_t:s0 tclass=fifo_file
Fixed in selinux-policy-3.3.1-63.fc9.noarch
I've noticed you've added a lot of courier stuff to the policy, which is very nice. But the paths are mostly wrong. What packages are you using as a base? You can find packages built using courier's own spec file here: http://apt.drzeus.cx/drzeus/9/x86_64/ http://apt.drzeus.cx/drzeus/9/i386/ http://apt.drzeus.cx/drzeus/8/x86_64/ Those should give you complete lists of where the files end up.
Could you just give me the output of rpm -ql This policy was submitted by people upstream
Created attachment 308485 [details] rpm -ql As there is quite a lot of files, I've included a file with all the dumps.
Fixed file context in selinux-policy-3.3.1-67.fc9.noarch
The file globs are now correct (although the old incorrect ones are still present), but there is still a policy problem. logwatch isn't allowed to execute a file with type courier_exec_t: type=1400 audit(1213497412.716:28): avc: denied { execute } for pid=27542 comm="0logwatch" name="sendmail" dev=dm-0 ino=24832 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_exec_t:s0 tclass=file
Any progress? I feel like we're very close to getting this solved once and for all.
Fixed in selinux-policy-3.3.1-68.fc9.noarch
No change I'm afraid. Policy still denies logwatch_t to execute courier_exec_t. I'm not sure everything is working as intended though. I have two F9 machines that I test this on, and the files in /etc/selinux/targeted/context/files differ. Oddly enough, rpm -V selinux-policy-targeted doesn't say anything about modified files on either system. The RPM database says their size is 0, which I take it means they're ghost files? My real question is why these aren't updated though, and how do I do that manually?
First off policy 68 was broken, try 69. This probably means that the policy was never loaded so you are still looking at the old policy. The change I added was to tell the system to use courier as a mailclient, This allows other domains/processes to transition to system_mail_t when running courier_exec_t. This should allow logwatch_t to send mail using courier. Fixed in selinux-policy-3.3.1-69.fc9.noarch
Almost. It properly transitions to system_mail_t now, but it needs to execute /usr/lib/courier/libexec/courier/submit (marked courier_exec_t) to put the message on the queue: type=1400 audit(1214274691.825:8): avc: denied { execute } for pid=4009 comm="sendmail" name="submit" dev=dm-0 ino=271483 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_exec_t:s0 tclass=file
Fixed in selinux-policy-3.3.1-71.fc9.noarch
If you queue up a build, I'll make sure it'll get tested tonight.
The execute permission now work. What's missing is that some rights did not get transferred over for the new courier_spool_t type. The following is missing: #============= system_mail_t ============== allow system_mail_t courier_spool_t:dir { write search create add_name }; allow system_mail_t courier_spool_t:file { create getattr append }; Errors: type=1400 audit(1214461712.526:19): avc: denied { search } for pid=9985 comm="submit" name="courier" dev=dm-0 ino=49165 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_spool_t:s0 tclass=dir type=1400 audit(1214461716.522:20): avc: denied { write } for pid=10253 comm="submitmkdir" name="tmp" dev=dm-0 ino=49173 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_spool_t:s0 tclass=dir type=1400 audit(1214461716.522:21): avc: denied { add_name } for pid=10253 comm="submitmkdir" name="121446" scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_spool_t:s0 tclass=dir type=1400 audit(1214461716.522:22): avc: denied { create } for pid=10253 comm="submitmkdir" name="121446" scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_spool_t:s0 tclass=dir type=1400 audit(1214461716.524:23): avc: denied { create } for pid=9985 comm="submit" name="1214461716.9985.smtp.fordonsservice.se" scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_spool_t:s0 tclass=file type=1400 audit(1214461716.525:24): avc: denied { append } for pid=9985 comm="submit" name="1214461716.9985.smtp.fordonsservice.se" dev=dm-0 ino=49193 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_spool_t:s0 tclass=file type=1400 audit(1214461716.525:25): avc: denied { getattr } for pid=9985 comm="submit" path="/var/spool/courier/tmp/121446/1214461716.9985.smtp.fordonsservice.se" dev=dm-0 ino=49193 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_spool_t:s0 tclass=file
ping
Fixed in selinux-policy-3.3.1-73.fc9.noarch Sorry I was on vacation...
No sweat. Wouldn't want you getting overworked and gone even longer. :) For some reason one permission didn't appear in the test run with the last policy: allow system_mail_t courier_spool_t:fifo_file write; type=1400 audit(1214920412.896:96): avc: denied { write } for pid=31935 comm="submit" name="trigger" dev=dm-0 ino=49183 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:courier_spool_t:s0 tclass=fifo_file Hopefully we're finally done after that addition.
Fixed in selinux-policy-3.3.1-75.fc9.noarch
I notice that there is no build for this version on koji yet. What's your work flow when it comes to marking stuff and there actually appearing a new package?
I mark them fixed all day long, and then build at the end of the day.
Reasonable enough. It's just the time zone differences that makes it easy for me to miss the build. Anyway, runcon seems to suggest that everything is as it should now. I'll see what a proper execution does in a few hours.
Everything ran like a charm. Thanks for all the hard work in getting this fixed.
I guess I should have said 17:00 EDT. :^)
Closing all bugs that have been in modified for over a month. Please reopen if the bug is not actually fixed.
The modifications have been working perfectly, up until yesterday. It seems anacron does things slightly different and triggers the following: type=1400 audit(1227865697.993:6): avc: denied { setuid } for pid=7421 comm="submit" capability=7 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:system_r:logwatch_t:s0 tclass=capability I'm not sure how to trigger new anacron runs, so I don't know how I can test any fixes though.
The problem here is the submit command? What is this?
submit is the program that does all the heavy lifting of actually getting the mail into the courier mail queue. "sendmail" in courier is just a formatting frontend. "submit" is the one doing the privileged work (i.e. modifying the spool directory).
If you chcon -t sendmail_exec_t /usr/bin/submit Does it work?
I'm afraid I haven't had time to fiddle with this yet. To get the ball rolling a bit though, do you have some tips for manually triggering an anacron run?
Ok, I've put some more time into this. After an upgrade to F10 and the latest courier, the original problem with logwatch was back. After running the following, everything works as it should: chcon -t sendmail_exec_t /usr/lib/courier/bin/sendmail So please add that to courier.fc and push to F10 updates. :)
Miroslav, add /usr/lib/courier/bin/sendmail -- gen_context(system_u:object_r:sendmail_exec_t,s0) to mta.fc
Fixed in selinux-policy-3.5.13-39.fc10.noarch
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'. 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 10'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 10 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
Closing as closed in the current release.