My apologies in advance if this turns out to be pebkac; I haven't investigated yet to my usual level of thoroughness. I wanted to get this out because I think it's fairly important, and to others the fix may be obvious. I've got two fairly identical F15 machines with the unconfined module disabled. One uses the default sendmail, the other uses exim. With sendmail, staff_u can send email with no problem. In fact, so can user_u. With exim, staff_u gets these: type=AVC msg=audit(1315968105.961:104340): avc: denied { setuid } for pid=19806 comm="exim" capability=7 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability type=AVC msg=audit(1315968105.969:104341): avc: denied { dac_override } for pid=19806 comm="exim" capability=1 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability type=AVC msg=audit(1315968105.969:104341): avc: denied { dac_read_search } for pid=19806 comm="exim" capability=2 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability type=AVC msg=audit(1315968105.977:104343): avc: denied { setuid } for pid=19809 comm="exim" capability=7 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability type=AVC msg=audit(1315968105.991:104345): avc: denied { dac_override } for pid=19806 comm="exim" capability=1 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability type=AVC msg=audit(1315968105.991:104345): avc: denied { dac_read_search } for pid=19806 comm="exim" capability=2 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability type=AVC msg=audit(1315968105.994:104346): avc: denied { setuid } for pid=19810 comm="exim" capability=7 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability That's with setenforce 1. With setenforce 0: type=AVC msg=audit(1315968165.404:104359): avc: denied { setuid } for pid=19817 comm="exim" capability=7 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability type=AVC msg=audit(1315968165.411:104360): avc: denied { dac_override } for pid=19817 comm="exim" capability=1 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability type=AVC msg=audit(1315968165.411:104360): avc: denied { append } for pid=19817 comm="exim" name="main.log" dev=vda2 ino=10422 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_log_t:s0 tclass=file type=AVC msg=audit(1315968165.411:104360): avc: denied { open } for pid=19817 comm="exim" name="main.log" dev=vda2 ino=10422 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_log_t:s0 tclass=file type=AVC msg=audit(1315968167.232:104363): avc: denied { write } for pid=19817 comm="exim" name="input" dev=vda2 ino=6255 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_spool_t:s0 tclass=dir type=AVC msg=audit(1315968167.232:104363): avc: denied { add_name } for pid=19817 comm="exim" name="1R3fQz-00059d-DV-D" scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_spool_t:s0 tclass=dir type=AVC msg=audit(1315968167.232:104363): avc: denied { create } for pid=19817 comm="exim" name="1R3fQz-00059d-DV-D" scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file type=AVC msg=audit(1315968167.232:104363): avc: denied { read write open } for pid=19817 comm="exim" name="1R3fQz-00059d-DV-D" dev=vda2 ino=3622 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file type=AVC msg=audit(1315968167.232:104364): avc: denied { setattr } for pid=19817 comm="exim" name="1R3fQz-00059d-DV-D" dev=vda2 ino=3622 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file type=AVC msg=audit(1315968167.232:104365): avc: denied { lock } for pid=19817 comm="exim" path="/var/spool/exim/input/1R3fQz-00059d-DV-D" dev=vda2 ino=3622 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file type=AVC msg=audit(1315968167.582:104366): avc: denied { remove_name } for pid=19817 comm="exim" name="hdr.19817" dev=vda2 ino=10464 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_spool_t:s0 tclass=dir type=AVC msg=audit(1315968167.582:104366): avc: denied { rename } for pid=19817 comm="exim" name="hdr.19817" dev=vda2 ino=10464 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file type=AVC msg=audit(1315968167.647:104367): avc: denied { append } for pid=19817 comm="exim" name="1R3fQz-00059d-DV" dev=vda2 ino=10465 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file type=AVC msg=audit(1315968167.737:104369): avc: denied { read write } for pid=19820 comm="exim" name="retry.lockfile" dev=vda2 ino=6311 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_spool_t:s0 tclass=file type=AVC msg=audit(1315968167.737:104369): avc: denied { open } for pid=19820 comm="exim" name="retry.lockfile" dev=vda2 ino=6311 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_spool_t:s0 tclass=file type=AVC msg=audit(1315968167.737:104370): avc: denied { lock } for pid=19820 comm="exim" path="/var/spool/exim/db/retry.lockfile" dev=vda2 ino=6311 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_spool_t:s0 tclass=file type=AVC msg=audit(1315968170.217:104371): avc: denied { unlink } for pid=19820 comm="exim" name="1R3fQz-00059d-DV" dev=vda2 ino=10465 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file In both cases, what I'm actually running, as staff_u, is /usr/sbin/exim robin ; in the second case , I enter date and hit ctrl-d, in the former case it just errors out. -Robin
Something else that exim needs, apparently to run pipe aliases properly: type=AVC msg=audit(1315979065.075:125464): avc: denied { read } for pid=29926 comm="exim" name="stat" dev=proc ino=4026532009 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file type=AVC msg=audit(1315979065.075:125464): avc: denied { open } for pid=29926 comm="exim" name="stat" dev=proc ino=4026532009 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file I can stick that in a separate ticket if you like. -Robin
No, that's fine. So you added a local policy looks like # cat myexim.te policy_module(myexim, 1.0) require{ type staff_t; role staff_r; } exim_domtrans(staff_t) role staff_r types exim_t; # make -f /usr/share/selinux/devel/Makefile myexim.pp # semodule -i myexim.pp
I'm confused, you're asking me to do that, yes? For testing, or do you expect me to leave that in forever? If the latter, why do I need to do that for exim, but not sendmail? -Robni
OK, that seems to fix the basic problem for staff_u. It doesn't fix it for anybody else (obviously), nor does it fix the pipe problem (which there may be a more general problem there; I'm posting to the mailing list about that). -Robin
(In reply to comment #3) > I'm confused, you're asking me to do that, yes? For testing, or do you expect > me to leave that in forever? If the latter, why do I need to do that for exim, > but not sendmail? > > -Robni It is for testing and if this looks good, we will add it to the default policy. Also I haven't read a sendmail bugzilla yet.
That was my point: sendmail doesn't need this fix, when everything else is exactly the same. That strikes me as odd, and worth investigating. Anyways, the fix seems to work, as far as it goes. Do you want me to split the pipe issues out into a separate bug, since it doesn't fix those? -Robin
A new bug is not necessary.
I found something else: procmail under exim can't send mail, but sendmail works. I don't really understand sesearch :), so here's my lame search for the rules in question: rlpowell@stodi> sh -c "sesearch -SC --allow | grep procmail | grep sendmail | grep -i trans" allow procmail_t sendmail_t : process { transition sigchld signal } ; allow sendmail_t procmail_t : process { transition sigchld } ; rlpowell@stodi> sh -c "sesearch -SC --allow | grep procmail | grep exim | grep -i trans" allow exim_t procmail_t : process transition ; Bizarrely, it seems that when procmail runs /usr/sbin/sendmail on my system, it ends up at sendmail_t instead of exim_t 0.o, which then tries to read/write exim directories, since it's actually exim. I've now got the following module to fix exim issues: - ------------------------- policy_module(myexim738118, 1.0) require{ type staff_t; role staff_r; type user_t; role user_r; type procmail_t; type proc_t; class file { read open }; } exim_domtrans(staff_t) role staff_r types exim_t; exim_domtrans(user_t) role user_r types exim_t; exim_domtrans(procmail_t) allow exim_t proc_t:file { read open }; - ------------------------- and it compiles fine, but when I try to install it: rlpowell@stodi> sudo semodule -i myexim738118.pp libsepol.expand_terule_helper: conflicting TE rule for (procmail_t, exim_exec_t:process): old was exim_t, new is sendmail_t libsepol.expand_module: Error during expand libsemanage.semanage_expand_sandbox: Expand module failed /usr/sbin/semodule: Failed! Which I am quite confused by; does it have "old" and "new" reversed? -Robin
This is because we have a rule that says if procmail executes an mta_exec_type it will transition to sendmail_t. Really we should start to eliminate some of the additional domains that we have for different mailers and combine them into one domain.
OK, so what do I do to make my server work? My whole Fedora transition project is now hanging on this. :( -Robin
OK, here's what I've got that seems to have things working for me: policy_module(myexim738118, 1.0) require{ type staff_t; role staff_r; type user_t; role user_r; type procmail_t; type proc_t; class file { read open }; type sendmail_t; type exim_log_t; type exim_spool_t; } exim_domtrans(staff_t) role staff_r types exim_t; exim_domtrans(user_t) role user_r types exim_t; allow exim_t proc_t:file { read open }; read_files_pattern(sendmail_t, exim_log_t, exim_log_t) manage_files_pattern(sendmail_t, exim_spool_t, exim_spool_t) manage_dirs_pattern(sendmail_t, exim_spool_t, exim_spool_t) Probably a better way to do that, but there it is. I really like that unified mail domain plan, fwiw. -Robin
One more I had to add: files_read_usr_files(exim_t) That's because exim was running mhonarc, which needs access to perl stuff: type=AVC msg=audit(09/18/2011 13:21:28.379:72299) : avc: denied { getattr } for pid=17195 comm=mhonarc path=/usr/share/perl5/strict.pm dev=vda2 ino=397745 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file type=AVC msg=audit(09/18/2011 13:21:28.380:72300) : avc: denied { open } for pid=17195 comm=mhonarc name=strict.pm dev=vda2 ino=397745 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file type=AVC msg=audit(09/18/2011 13:21:28.380:72300) : avc: denied { read } for pid=17195 comm=mhonarc name=strict.pm dev=vda2 ino=397745 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file type=AVC msg=audit(09/18/2011 13:21:28.380:72301) : avc: denied { ioctl } for pid=17195 comm=mhonarc path=/usr/share/perl5/strict.pm dev=vda2 ino=397745 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file which exim doesn't have. I'm not sure, again, whether that should be a separate ticket or not; let me know. -Robin
Ok, I am adding fixes for Fedora16 and I will start with combining of domains in Fedora17.
(In reply to comment #13) > Ok, I am adding fixes for Fedora16 and Of course these fixes I am also adding to F15.
Fixed in -41.fc15 release which I will build today.
This seems to be mostly working. The only thing I'm getting now is: type=AVC msg=audit(10/07/2011 17:35:42.110:342760) : avc: denied { read } for pid=19409 comm=sendmail path=/tmp/RsWNhBkN (deleted) dev=vda2 ino=137054 scontext=staff_u:staff_r:exim_t:s0 tcontext=staff_u:object_r:user_mail_tmp_t:s0 tclass=file type=AVC msg=audit(10/07/2011 17:35:42.471:342763) : avc: denied { read write } for pid=19412 comm=procmail name=4 dev=devpts ino=7 scontext=staff_u:staff_r:procmail_t:s0 tcontext=staff_u:object_r:user_devpts_t:s0 tclass=chr_file That was from a manual run of mailx -v; I'm guessing the second was procmail trying to talk back to me for some reason. -Robin
Ok, could you reproduce this latest AVC msgs and add me output of # ausearch -m avc -ts recent
selinux-policy-3.9.16-48.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-48.fc15
Package selinux-policy-3.9.16-48.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.16-48.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16023/selinux-policy-3.9.16-48.fc15 then log in and leave karma (feedback).
selinux-policy-3.9.16-48.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.