Bug 481446 - Recompile of mailman's config causes SElinux denials
Recompile of mailman's config causes SElinux denials
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: mailman (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Novotny
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-24 18:35 EST by Pierre Ossman
Modified: 2009-04-06 16:23 EDT (History)
1 user (show)

See Also:
Fixed In Version: 2.1.11-5.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-06 16:23:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
a script for the config change (94 bytes, text/plain)
2009-03-31 10:09 EDT, Daniel Novotny
no flags Details

  None (edit)
Description Pierre Ossman 2009-01-24 18:35:17 EST
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.
Comment 1 Daniel Walsh 2009-01-26 13:11:46 EST
You have a labeling problem.

restorecon -R -v /var/lib
Comment 2 Pierre Ossman 2009-01-26 13:59:43 EST
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.
Comment 3 Daniel Walsh 2009-01-26 14:05:57 EST
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.
Comment 4 Pierre Ossman 2009-01-26 14:17:15 EST
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
Comment 5 Daniel Walsh 2009-01-27 08:54:38 EST
Well  this is going to be a problem, since we do not want a confined domain to be able to rewrite its own executable.
Comment 6 Pierre Ossman 2009-03-29 05:41:56 EDT
Has there been any progress on this front?
Comment 7 Daniel Walsh 2009-03-30 10:57:42 EDT
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.
Comment 8 Daniel Novotny 2009-03-31 07:40:43 EDT
(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)
Comment 9 Daniel Novotny 2009-03-31 10:09:20 EDT
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
Comment 10 Pierre Ossman 2009-03-31 15:25:57 EDT
What does upstream say about it? Being able to properly contain mailman with selinux should be something that they'd care about.
Comment 11 Daniel Novotny 2009-04-01 05:34:11 EDT
(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.
Comment 12 Daniel Novotny 2009-04-02 07:58:05 EDT
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
Comment 13 Daniel Novotny 2009-04-02 09:58:41 EDT
...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
Comment 14 Fedora Update System 2009-04-02 09:59:47 EDT
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
Comment 15 Pierre Ossman 2009-04-02 10:13:39 EDT
That's reasonable I guess. Thanks.
Comment 16 Fedora Update System 2009-04-02 22:25:51 EDT
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
Comment 17 Fedora Update System 2009-04-06 16:23:42 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.