After an upgrade from F8 to F10, SELinux has started to make life very difficult for mailman: type=1400 audit(1232837475.922:4): avc: denied { write } for pid=1888 comm="mailmanctl" name="Mailman" dev=dm-0 ino=788888 scontext=system_u:system_r:mailman_mail_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir type=1400 audit(1232837476.536:5): avc: denied { write } for pid=1910 comm="python" name="Mailman" dev=dm-0 ino=788888 scontext=system_u:system_r:mailman_mail_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir type=1400 audit(1232837476.645:6): avc: denied { write } for pid=1911 comm="python" name="Mailman" dev=dm-0 ino=788888 scontext=system_u:system_r:mailman_mail_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir type=1400 audit(1232837476.756:7): avc: denied { write } for pid=1912 comm="python" name="Mailman" dev=dm-0 ino=788888 scontext=system_u:system_r:mailman_mail_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir type=1400 audit(1232837476.828:8): avc: denied { write } for pid=1913 comm="python" name="Mailman" dev=dm-0 ino=788888 scontext=system_u:system_r:mailman_mail_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir type=1400 audit(1232837476.865:9): avc: denied { write } for pid=1914 comm="python" name="Mailman" dev=dm-0 ino=788888 scontext=system_u:system_r:mailman_mail_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir type=1400 audit(1232837476.931:10): avc: denied { write } for pid=1915 comm="python" name="Mailman" dev=dm-0 ino=788888 scontext=system_u:system_r:mailman_mail_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir type=1400 audit(1232837477.004:11): avc: denied { write } for pid=1916 comm="python" name="Mailman" dev=dm-0 ino=788888 scontext=system_u:system_r:mailman_mail_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir type=1400 audit(1232837477.062:12): avc: denied { write } for pid=1917 comm="python" name="Mailman" dev=dm-0 ino=788888 scontext=system_u:system_r:mailman_mail_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir type=1400 audit(1232838001.607:27): avc: denied { read } for pid=2525 comm="gate_news" path="inotify" dev=inotifyfs ino=1 scontext=system_u:system_r:mailman_queue_t:s0-s0:c0.c1023 tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir type=1400 audit(1232838002.341:28): avc: denied { write } for pid=2525 comm="gate_news" name="Mailman" dev=dm-0 ino=788888 scontext=system_u:system_r:mailman_queue_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=dir The ino 788888 seem to be that mailman wants to regenerate the .pyc in /usr/lib/mailman (which is the file for the specificed inode), since I get this once I go into permissive mode: type=1400 audit(1232838302.527:41): avc: denied { write } for pid=2626 comm="gate_news" name="Mailman" dev=dm-0 ino=788888 scontext=system_u:system_r:mailman_queue_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=dir type=1400 audit(1232838302.539:42): avc: denied { remove_name } for pid=2626 comm="gate_news" name="mm_cfg.pyc" dev=dm-0 ino=790783 scontext=system_u:system_r:mailman_queue_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=dir type=1400 audit(1232838302.539:43): avc: denied { unlink } for pid=2626 comm="gate_news" name="mm_cfg.pyc" dev=dm-0 ino=790783 scontext=system_u:system_r:mailman_queue_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=file type=1400 audit(1232838302.539:44): avc: denied { add_name } for pid=2626 comm="gate_news" name="mm_cfg.pyc" scontext=system_u:system_r:mailman_queue_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=dir type=1400 audit(1232838302.540:45): avc: denied { create } for pid=2626 comm="gate_news" name="mm_cfg.pyc" scontext=system_u:system_r:mailman_queue_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=file type=1400 audit(1232838302.543:46): avc: denied { write } for pid=2626 comm="gate_news" name="mm_cfg.pyc" dev=dm-0 ino=786433 scontext=system_u:system_r:mailman_queue_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=file Also note the problems it causes for mailman and inotify.
You have a labeling problem. restorecon -R -v /var/lib
Huh? 788888 is /usr/lib/mailman/Mailman, not something under /var/lib. Running a restorecon on either of them doesn't result in any relabling.
Ok, this looks like a packaging problem, your python code (*py) has been updated but not the compiled code, so a confined python app is trying to write the files. You can fix this my executing python on pychecker directly on the python code. yum install pychecker pychecker /usr/lib/mailman/*.py Which will create the new pyc files. The inotify bugs are reported elsewhere.
Actually, the mm_cfg.py file is the configuration for mailman so the user is supposed to modify it (resulting in a recompile once mailman runs). Blame the mailman guys for not placing it in /etc/. :) They do have a symlink there though: lrwxrwxrwx 1 root mailman 34 2009-01-24 22:13 /etc/mailman/mm_cfg.py -> /usr/lib/mailman/Mailman/mm_cfg.py
Well this is going to be a problem, since we do not want a confined domain to be able to rewrite its own executable.
Has there been any progress on this front?
Can this file be moved to a different file/directory, It should not be in /usr since this is supposed to able to be readonly. If you moved it to /var/lib/mailman writing SELinux policy for it would become much easier.
(In reply to comment #7) > Can this file be moved to a different file/directory, It should not be in /usr > since this is supposed to able to be readonly. > > If you moved it to /var/lib/mailman writing SELinux policy for it would become > much easier. hmmm, very many of Mailman sources contain "from Mailman import mm_cfg" - now looking for a clean and elegant way to move the file without changing all of them (and without the patch being long and ugly)
Created attachment 337308 [details] a script for the config change btw - this is the work-around script I added into the F11 version of mailman, which has to be run manually after changing the config file (which does not happen very often) maybe I should add it to F10, too. see bug 484328
What does upstream say about it? Being able to properly contain mailman with selinux should be something that they'd care about.
(In reply to comment #10) > What does upstream say about it? Being able to properly contain mailman with > selinux should be something that they'd care about. I asked upstream right now. Let's see what they think about it.
if the script from comment #9 will be run in the /etc/init.d/mailman script, the configuration will be compiled every time you change it, because you have to restart mailman nevertheless... what do you think about this solution? I asked upstream if it's acceptable
...so I used the above-mentioned solution: the one-liner which compiles the config file is run in /etc/init.d/mailman - this way AVC denials do not appear the change is in mailman-2.1.11-5.fc10
mailman-2.1.11-5.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/mailman-2.1.11-5.fc10
That's reasonable I guess. Thanks.
mailman-2.1.11-5.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 mailman'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3308
mailman-2.1.11-5.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.