Hi,
I have an issue I would like to fix properly.
I have a policy for mediawiki defined this way:
apache_content_template(mediawiki) apache_search_sys_content(httpd_mediawiki_script_t)
/var/www/mediawiki/bin(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_exec_t,s0) /var/www/mediawiki/images(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0) /var/www/mediawiki/cache(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0)
And it works fine. The trouble occurs when you upload a new version of an existing file (any file goes under images, by the way) I assume mediawiki in this case creates a file in some temp directory, removes original file and then moves the file in place. This causes the context to be set like this:
d/d6: -rw-r--r-- apache apache system_u:object_r:httpd_tmp_t:s0 Speedtest.png
instead of "normal"
d/d3: -rw-r--r-- apache apache system_u:object_r:httpd_mediawiki_script_rw_t:s0 PuTTY2.png
Here are related AVCs:
time->Mon Oct 18 13:45:03 2010 type=SYSCALL msg=audit(1287409503.893:6728): arch=c000003e syscall=4 success=no exit=-13 a0=7fff25eb8490 a1=7fff25eb53c0 a2=7fff25eb53c0 a3=0 items=0 ppid=14205 pid=14206 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) comm="convert" exe="/usr/bin/convert" subj=system_u:system_r:httpd_mediawiki_script_t:s0 key=(null) type=AVC msg=audit(1287409503.893:6728): avc: denied { getattr } for pid=14206 comm="convert" path="/var/www/mediawiki/images/d/d6/Speedtest.png" dev=sda1 ino=737287 scontext=system_u:system_r:httpd_mediawiki_script_t:s0 tcontext=system_u:object_r:httpd_tmp_t:s0 tclass=file ---- time->Mon Oct 18 13:45:03 2010 type=SYSCALL msg=audit(1287409503.893:6729): arch=c000003e syscall=2 success=no exit=-13 a0=7fff25eb8490 a1=0 a2=1b6 a3=0 items=0 ppid=14205 pid=14206 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) comm="convert" exe="/usr/bin/convert" subj=system_u:system_r:httpd_mediawiki_script_t:s0 key=(null) type=AVC msg=audit(1287409503.893:6729): avc: denied { read } for pid=14206 comm="convert" name="Speedtest.png" dev=sda1 ino=737287 scontext=system_u:system_r:httpd_mediawiki_script_t:s0 tcontext=system_u:object_r:httpd_tmp_t:s0 tclass=file
I'd rather not allow mediawiki access to generic httpd_tmp_t, so I wonder if there is a way to enforce the proper context when file is being moved in place?
Thank you, Vadym
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/18/2010 10:46 AM, Vadym Chepkov wrote:
Hi,
I have an issue I would like to fix properly.
I have a policy for mediawiki defined this way:
apache_content_template(mediawiki) apache_search_sys_content(httpd_mediawiki_script_t)
/var/www/mediawiki/bin(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_exec_t,s0) /var/www/mediawiki/images(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0) /var/www/mediawiki/cache(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0)
And it works fine. The trouble occurs when you upload a new version of an existing file (any file goes under images, by the way) I assume mediawiki in this case creates a file in some temp directory, removes original file and then moves the file in place. This causes the context to be set like this:
d/d6: -rw-r--r-- apache apache system_u:object_r:httpd_tmp_t:s0 Speedtest.png
instead of "normal"
d/d3: -rw-r--r-- apache apache system_u:object_r:httpd_mediawiki_script_rw_t:s0 PuTTY2.png
Here are related AVCs:
time->Mon Oct 18 13:45:03 2010 type=SYSCALL msg=audit(1287409503.893:6728): arch=c000003e syscall=4 success=no exit=-13 a0=7fff25eb8490 a1=7fff25eb53c0 a2=7fff25eb53c0 a3=0 items=0 ppid=14205 pid=14206 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) comm="convert" exe="/usr/bin/convert" subj=system_u:system_r:httpd_mediawiki_script_t:s0 key=(null) type=AVC msg=audit(1287409503.893:6728): avc: denied { getattr } for pid=14206 comm="convert" path="/var/www/mediawiki/images/d/d6/Speedtest.png" dev=sda1 ino=737287 scontext=system_u:system_r:httpd_mediawiki_script_t:s0 tcontext=system_u:object_r:httpd_tmp_t:s0 tclass=file
time->Mon Oct 18 13:45:03 2010 type=SYSCALL msg=audit(1287409503.893:6729): arch=c000003e syscall=2 success=no exit=-13 a0=7fff25eb8490 a1=0 a2=1b6 a3=0 items=0 ppid=14205 pid=14206 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) comm="convert" exe="/usr/bin/convert" subj=system_u:system_r:httpd_mediawiki_script_t:s0 key=(null) type=AVC msg=audit(1287409503.893:6729): avc: denied { read } for pid=14206 comm="convert" name="Speedtest.png" dev=sda1 ino=737287 scontext=system_u:system_r:httpd_mediawiki_script_t:s0 tcontext=system_u:object_r:httpd_tmp_t:s0 tclass=file
I'd rather not allow mediawiki access to generic httpd_tmp_t, so I wonder if there is a way to enforce the proper context when file is being moved in place?
Thank you, Vadym -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Can you find the code that is doing the mv and add a restorecon, or change it to a cp followed by a rm.
On Mon, Oct 18, 2010 at 10:52 AM, Daniel J Walsh dwalsh@redhat.com wrote:
Can you find the code that is doing the mv and add a restorecon, or change it to a cp followed by a rm.
And grant mediawiki permissions to run restorecon, gee, I am not sure of this. So the only way is to change the code? Will try to open ticket with mediawiki then.
Thanks, Vadym
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/18/2010 11:07 AM, Vadym Chepkov wrote:
On Mon, Oct 18, 2010 at 10:52 AM, Daniel J Walsh dwalsh@redhat.com wrote:
Can you find the code that is doing the mv and add a restorecon, or change it to a cp followed by a rm.
And grant mediawiki permissions to run restorecon, gee, I am not sure of this. So the only way is to change the code? Will try to open ticket with mediawiki then.
Thanks, Vadym -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Letting code run restorecon without a transition means does not give the code added priv. You can specify the labels that mediawiki can relabel between. I would prefer mediawiki to not use /tmp at all, but to use a directory that is not usable by users. Say create a subdir of the final dir or create the files with an extension before renaming.
On 10/18/2010 04:46 PM, Vadym Chepkov wrote:
Hi,
I have an issue I would like to fix properly.
I have a policy for mediawiki defined this way:
apache_content_template(mediawiki) apache_search_sys_content(httpd_mediawiki_script_t)
/var/www/mediawiki/bin(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_exec_t,s0) /var/www/mediawiki/images(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0) /var/www/mediawiki/cache(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0)
Vadym, we shipped the mediawiki policy in Fedora 13+. Any chance you have some of these Fedora release?
Regards, Miroslav
Thank you, Vadym -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Oct 19, 2010, at 3:17 AM, Miroslav Grepl wrote:
On 10/18/2010 04:46 PM, Vadym Chepkov wrote:
Hi,
I have an issue I would like to fix properly.
I have a policy for mediawiki defined this way:
apache_content_template(mediawiki) apache_search_sys_content(httpd_mediawiki_script_t)
/var/www/mediawiki/bin(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_exec_t,s0) /var/www/mediawiki/images(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0) /var/www/mediawiki/cache(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0)
Vadym, we shipped the mediawiki policy in Fedora 13+. Any chance you have some of these Fedora release?
This package is usually very behind. mediawiki 1.15.5 and 1.16.0 were released back in July and they are security releases no less, but Fedora still has 1.15.4 Anyway, I always install directly from mediawiki subversion tag. I don't need multi-site feature and other then that I don't see any other patches that would prevent the problem I have. I tried to check what selinux policy does Fedora provide and I found just one line in selinux-policy-3.7.19-62.fc13.src.rpm : /var/cache/mediawiki(/.*)? gen_context(system_u:object_r:httpd_cache_t,s0)
And I can assure you it's not enough. I suspect whoever uses mediawiki on Fedora either just turns SELinux off or has httpd_unified on.
Vadym
On 10/19/2010 01:58 PM, Vadym Chepkov wrote:
On Oct 19, 2010, at 3:17 AM, Miroslav Grepl wrote:
On 10/18/2010 04:46 PM, Vadym Chepkov wrote:
Hi,
I have an issue I would like to fix properly.
I have a policy for mediawiki defined this way:
apache_content_template(mediawiki) apache_search_sys_content(httpd_mediawiki_script_t)
/var/www/mediawiki/bin(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_exec_t,s0) /var/www/mediawiki/images(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0) /var/www/mediawiki/cache(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0)
Vadym, we shipped the mediawiki policy in Fedora 13+. Any chance you have some of these Fedora release?
This package is usually very behind. mediawiki 1.15.5 and 1.16.0 were released back in July and they are security releases no less, but Fedora still has 1.15.4 Anyway, I always install directly from mediawiki subversion tag. I don't need multi-site feature and other then that I don't see any other patches that would prevent the problem I have. I tried to check what selinux policy does Fedora provide and I found just one line in selinux-policy-3.7.19-62.fc13.src.rpm :
The mediawiki policy was added to selinux-policy-3.7.19-65.fc13 policy which should be available from the stable repo now. So you can update your policy and try to test the mediawiki policy which we shipped and you can help us to improve this policy.
Miroslav
/var/cache/mediawiki(/.*)? gen_context(system_u:object_r:httpd_cache_t,s0)
And I can assure you it's not enough. I suspect whoever uses mediawiki on Fedora either just turns SELinux off or has httpd_unified on.
Vadym
On Oct 19, 2010, at 9:33 AM, Miroslav Grepl wrote:
On 10/19/2010 01:58 PM, Vadym Chepkov wrote:
On Oct 19, 2010, at 3:17 AM, Miroslav Grepl wrote:
On 10/18/2010 04:46 PM, Vadym Chepkov wrote:
Hi,
I have an issue I would like to fix properly.
I have a policy for mediawiki defined this way:
apache_content_template(mediawiki) apache_search_sys_content(httpd_mediawiki_script_t)
/var/www/mediawiki/bin(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_exec_t,s0) /var/www/mediawiki/images(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0) /var/www/mediawiki/cache(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0)
Vadym, we shipped the mediawiki policy in Fedora 13+. Any chance you have some of these Fedora release?
This package is usually very behind. mediawiki 1.15.5 and 1.16.0 were released back in July and they are security releases no less, but Fedora still has 1.15.4 Anyway, I always install directly from mediawiki subversion tag. I don't need multi-site feature and other then that I don't see any other patches that would prevent the problem I have. I tried to check what selinux policy does Fedora provide and I found just one line in selinux-policy-3.7.19-62.fc13.src.rpm :
The mediawiki policy was added to selinux-policy-3.7.19-65.fc13 policy which should be available from the stable repo now. So you can update your policy and try to test the mediawiki policy which we shipped and you can help us to improve this policy.
Yep, I see it now. There are several scripts in the package without proper context:
/usr/share/mediawiki/bin /usr/share/mediawiki/bin/svnstat /usr/share/mediawiki/bin/ulimit-tvf.sh /usr/share/mediawiki/bin/ulimit.sh /usr/share/mediawiki/bin/ulimit4.sh
I had them as httpd_mediawiki_script_exec_t, because ulimit scripts are definitely used: that's what I had to give them :
apache_search_sys_content(httpd_mediawiki_script_t) fs_rw_anon_inodefs_files(httpd_mediawiki_script_t) allow httpd_mediawiki_script_t httpd_t:file read; allow httpd_mediawiki_script_t self:process setrlimit;
I wasn't able to compile this policy on RHEL :( It uses 'permissive' domain, which is not available there. Why is it used, by the way? Does it mean "work in progress" ?
Thanks, Vadym
On 10/20/2010 01:35 AM, Vadym Chepkov wrote:
On Oct 19, 2010, at 9:33 AM, Miroslav Grepl wrote:
On 10/19/2010 01:58 PM, Vadym Chepkov wrote:
On Oct 19, 2010, at 3:17 AM, Miroslav Grepl wrote:
On 10/18/2010 04:46 PM, Vadym Chepkov wrote:
Hi,
I have an issue I would like to fix properly.
I have a policy for mediawiki defined this way:
apache_content_template(mediawiki) apache_search_sys_content(httpd_mediawiki_script_t)
/var/www/mediawiki/bin(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_exec_t,s0) /var/www/mediawiki/images(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0) /var/www/mediawiki/cache(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0)
Vadym, we shipped the mediawiki policy in Fedora 13+. Any chance you have some of these Fedora release?
This package is usually very behind. mediawiki 1.15.5 and 1.16.0 were released back in July and they are security releases no less, but Fedora still has 1.15.4 Anyway, I always install directly from mediawiki subversion tag. I don't need multi-site feature and other then that I don't see any other patches that would prevent the problem I have. I tried to check what selinux policy does Fedora provide and I found just one line in selinux-policy-3.7.19-62.fc13.src.rpm :
The mediawiki policy was added to selinux-policy-3.7.19-65.fc13 policy which should be available from the stable repo now. So you can update your policy and try to test the mediawiki policy which we shipped and you can help us to improve this policy.
Yep, I see it now. There are several scripts in the package without proper context:
/usr/share/mediawiki/bin /usr/share/mediawiki/bin/svnstat /usr/share/mediawiki/bin/ulimit-tvf.sh /usr/share/mediawiki/bin/ulimit.sh /usr/share/mediawiki/bin/ulimit4.sh
I had them as httpd_mediawiki_script_exec_t, because ulimit scripts are definitely used: that's what I had to give them :
apache_search_sys_content(httpd_mediawiki_script_t) fs_rw_anon_inodefs_files(httpd_mediawiki_script_t) allow httpd_mediawiki_script_t httpd_t:file read; allow httpd_mediawiki_script_t self:process setrlimit;
So does it work with these rules, labels and with the policy which we shipped?
I wasn't able to compile this policy on RHEL :( It uses 'permissive' domain, which is not available there. Why is it used, by the way? Does it mean "work in progress" ?
We can push out a new policy as permissive domain and simply collect AVC messages. Users don’t have to switch to permissive mode globally and they can stay in the enforcing mode.
Miroslav
Thanks, Vadym
On Oct 20, 2010, at 3:17 AM, Miroslav Grepl wrote:
On 10/20/2010 01:35 AM, Vadym Chepkov wrote:
On Oct 19, 2010, at 9:33 AM, Miroslav Grepl wrote:
On 10/19/2010 01:58 PM, Vadym Chepkov wrote:
On Oct 19, 2010, at 3:17 AM, Miroslav Grepl wrote:
On 10/18/2010 04:46 PM, Vadym Chepkov wrote:
Hi,
I have an issue I would like to fix properly.
I have a policy for mediawiki defined this way:
apache_content_template(mediawiki) apache_search_sys_content(httpd_mediawiki_script_t)
/var/www/mediawiki/bin(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_exec_t,s0) /var/www/mediawiki/images(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0) /var/www/mediawiki/cache(/.*)? gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0)
Vadym, we shipped the mediawiki policy in Fedora 13+. Any chance you have some of these Fedora release?
This package is usually very behind. mediawiki 1.15.5 and 1.16.0 were released back in July and they are security releases no less, but Fedora still has 1.15.4 Anyway, I always install directly from mediawiki subversion tag. I don't need multi-site feature and other then that I don't see any other patches that would prevent the problem I have. I tried to check what selinux policy does Fedora provide and I found just one line in selinux-policy-3.7.19-62.fc13.src.rpm :
The mediawiki policy was added to selinux-policy-3.7.19-65.fc13 policy which should be available from the stable repo now. So you can update your policy and try to test the mediawiki policy which we shipped and you can help us to improve this policy.
Yep, I see it now. There are several scripts in the package without proper context:
/usr/share/mediawiki/bin /usr/share/mediawiki/bin/svnstat /usr/share/mediawiki/bin/ulimit-tvf.sh /usr/share/mediawiki/bin/ulimit.sh /usr/share/mediawiki/bin/ulimit4.sh
I had them as httpd_mediawiki_script_exec_t, because ulimit scripts are definitely used: that's what I had to give them :
apache_search_sys_content(httpd_mediawiki_script_t) fs_rw_anon_inodefs_files(httpd_mediawiki_script_t) allow httpd_mediawiki_script_t httpd_t:file read; allow httpd_mediawiki_script_t self:process setrlimit;
So does it work with these rules, labels and with the policy which we shipped?
I will install mediawiki somewhere on fedora and will try it out. Even after I removed 'permissive' I can't compile it on EPEL:
Compiling targeted mediawiki module /usr/bin/checkmodule: loading policy configuration from tmp/mediawiki.tmp mediawiki.te:26:ERROR 'syntax error' at token ':' on line 99670: allow tmp_t:dir { getattr search }; #line 26 /usr/bin/checkmodule: error(s) encountered while parsing configuration make: *** [tmp/mediawiki.mod] Error 1
line 26 is this userdom_read_user_tmp_files(httpd_mediawiki_script_t)
I wasn't able to compile this policy on RHEL :( It uses 'permissive' domain, which is not available there. Why is it used, by the way? Does it mean "work in progress" ?
We can push out a new policy as permissive domain and simply collect AVC messages. Users don’t have to switch to permissive mode globally and they can stay in the enforcing mode.
Miroslav
Thanks, Vadym
On 10/20/2010 01:23 PM, Vadym Chepkov wrote:
On Oct 20, 2010, at 3:17 AM, Miroslav Grepl wrote:
On 10/20/2010 01:35 AM, Vadym Chepkov wrote:
On Oct 19, 2010, at 9:33 AM, Miroslav Grepl wrote:
On 10/19/2010 01:58 PM, Vadym Chepkov wrote:
On Oct 19, 2010, at 3:17 AM, Miroslav Grepl wrote:
On 10/18/2010 04:46 PM, Vadym Chepkov wrote: > Hi, > > I have an issue I would like to fix properly. > > I have a policy for mediawiki defined this way: > > apache_content_template(mediawiki) > apache_search_sys_content(httpd_mediawiki_script_t) > > /var/www/mediawiki/bin(/.*)? > gen_context(system_u:object_r:httpd_mediawiki_script_exec_t,s0) > /var/www/mediawiki/images(/.*)? > gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0) > /var/www/mediawiki/cache(/.*)? > gen_context(system_u:object_r:httpd_mediawiki_script_rw_t,s0) Vadym, we shipped the mediawiki policy in Fedora 13+. Any chance you have some of these Fedora release?
This package is usually very behind. mediawiki 1.15.5 and 1.16.0 were released back in July and they are security releases no less, but Fedora still has 1.15.4 Anyway, I always install directly from mediawiki subversion tag. I don't need multi-site feature and other then that I don't see any other patches that would prevent the problem I have. I tried to check what selinux policy does Fedora provide and I found just one line in selinux-policy-3.7.19-62.fc13.src.rpm :
The mediawiki policy was added to selinux-policy-3.7.19-65.fc13 policy which should be available from the stable repo now. So you can update your policy and try to test the mediawiki policy which we shipped and you can help us to improve this policy.
Yep, I see it now. There are several scripts in the package without proper context:
/usr/share/mediawiki/bin /usr/share/mediawiki/bin/svnstat /usr/share/mediawiki/bin/ulimit-tvf.sh /usr/share/mediawiki/bin/ulimit.sh /usr/share/mediawiki/bin/ulimit4.sh
I had them as httpd_mediawiki_script_exec_t, because ulimit scripts are definitely used: that's what I had to give them :
apache_search_sys_content(httpd_mediawiki_script_t) fs_rw_anon_inodefs_files(httpd_mediawiki_script_t) allow httpd_mediawiki_script_t httpd_t:file read; allow httpd_mediawiki_script_t self:process setrlimit;
So does it work with these rules, labels and with the policy which we shipped?
I will install mediawiki somewhere on fedora and will try it out.
OK
Even after I removed 'permissive' I can't compile it on EPEL:
Compiling targeted mediawiki module /usr/bin/checkmodule: loading policy configuration from tmp/mediawiki.tmp mediawiki.te:26:ERROR 'syntax error' at token ':' on line 99670: allow tmp_t:dir { getattr search }; #line 26 /usr/bin/checkmodule: error(s) encountered while parsing configuration make: *** [tmp/mediawiki.mod] Error 1
line 26 is this userdom_read_user_tmp_files(httpd_mediawiki_script_t)
Yes, this interface is called in the template interfaces in RHEL. Two arguments are needed:
userdom_read_user_tmp_files(prefix,domain)
So just try to remove this interface.
I wasn't able to compile this policy on RHEL :( It uses 'permissive' domain, which is not available there. Why is it used, by the way? Does it mean "work in progress" ?
We can push out a new policy as permissive domain and simply collect AVC messages. Users don’t have to switch to permissive mode globally and they can stay in the enforcing mode.
Miroslav
Thanks, Vadym
On Oct 20, 2010, at 3:17 AM, Miroslav Grepl wrote:
So does it work with these rules, labels and with the policy which we shipped?
The mediawiki rpm in Fedora is unusable, the mere fact they put site into /var/www/wiki breaks ability to have site.com/wiki/ with short urls (mod_rewrite). But this is beyond the scope of this distro.
I just installed the unmodified mediawiki into /var/www/mediawiki and set the following context:
/var/www/mediawiki(/.*)? system_u:object_r:httpd_mediawiki_content_t:s0 /var/www/mediawiki/images(/.*)? system_u:object_r:httpd_mediawiki_rw_content_t:s0 /var/www/mediawiki/config(/.*)? system_u:object_r:httpd_mediawiki_rw_content_t:s0 /var/www/mediawiki/cache(/.*)? system_u:object_r:httpd_cache_t:s0 /var/www/mediawiki/bin(/.*)? system_u:object_r:httpd_mediawiki_script_exec_t:s0
1. Since mediawiki package claims to support multiple instances, I think policy should heave some sort of regex: /var/www/([^/]*wiki(/.*)? for example 2. the standard policy makes everything writable by default and only .php wiles protected. Don't think its right. what about .php5 or .inc files that comes with extensions or READMEs for that matter? I thought it should be "least privileges". Mediwaiki needs write access only under "images" where it stores uploaded content and under 'config' it has to create one file LocalSettings.php during initial installation. Which then should be manually copied into "main" directory. Nothing else. 3. mediawiki 'bin' scripts are not included into policy at all. I added them and here are the AVC I still got:
---- time->Mon Oct 25 09:47:41 2010 type=SYSCALL msg=audit(1288014461.588:565): arch=40000003 syscall=11 success=yes exit=0 a0=97cea00 a1=97cea28 a2=97cd660 a3=97cea28 items=0 ppid=6259 pid=6269 auid=1001 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=10 comm="ulimit4.sh" exe="/bin/bash" subj=unconfined_u:system_r:httpd_mediawiki_script_t:s0 key=(null) type=AVC msg=audit(1288014461.588:565): avc: denied { read } for pid=6269 comm="ulimit4.sh" path="/var/www/mediawiki/cache/l10n_cache-en.cdb" dev=dm-3 ino=10174 scontext=unconfined_u:system_r:httpd_mediawiki_script_t:s0 tcontext=unconfined_u:object_r:httpd_cache_t:s0 tclass=file ---- time->Mon Oct 25 09:47:41 2010 type=SYSCALL msg=audit(1288014461.597:566): arch=40000003 syscall=75 success=yes exit=0 a0=0 a1=bfbb6ddc a2=41aff4 a3=0 items=0 ppid=6259 pid=6269 auid=1001 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=10 comm="ulimit4.sh" exe="/bin/bash" subj=unconfined_u:system_r:httpd_mediawiki_script_t:s0 key=(null) type=AVC msg=audit(1288014461.597:566): avc: denied { setrlimit } for pid=6269 comm="ulimit4.sh" scontext=unconfined_u:system_r:httpd_mediawiki_script_t:s0 tcontext=unconfined_u:system_r:httpd_mediawiki_script_t:s0 tclass=process
So, I think 'cache' needs to be marked as httpd_mediawiki_rw_content_t instead of httpd_cache_t and
allow httpd_mediawiki_script_t self:process setrlimit;
needs to be added.
I didn't get denials because of the "tmp" files that has started this thread, so it's a good sign at least.
Now I will try to adapt the policy for rhel5 and report back, I wasn't lucky at the first try, probably conflict with my previously defined mediawiki policy. Or maybe I should remove mediawiki.if file when I compile it there?
Thanks, Vadym
selinux@lists.fedoraproject.org