I am using the gallery2 tar ball from http://codex.gallery2.org/Downloads ; it stays more up to date. They have a policy for selinux, but the log still had AVCs in it and denials that prevented gallery2 and specifically the watermark plugin from working. File and directory permissions were an issue. One of the directories is shared by samba so it has the context of public_content_rw_t.
I used audit2allow to get things working, but I would like someone more knowledgeable than me to take a look as see if I have opened any gaping holes and if so, how to best address the issue.
policy_module(gallery, 1.0)
require { type unlabeled_t; type httpd_t; type httpd_tmp_t; type httpd_sys_script_t; type public_content_rw_t; class file { read write unlink }; class dir { write remove_name add_name }; }
#============= httpd_sys_script_t ============== allow httpd_sys_script_t unlabeled_t:file { read write }; allow httpd_sys_script_t httpd_tmp_t:file { getattr read };
#============= httpd_t ============== allow httpd_t public_content_rw_t:dir { write remove_name add_name }; allow httpd_t public_content_rw_t:file unlink;
Thanks, John Griffiths
On Thu, 30 Aug 2007 14:56:48 -0400 John Griffiths fedora01@grifent.com wrote:
I am using the gallery2 tar ball from http://codex.gallery2.org/Downloads ; it stays more up to date. They have a policy for selinux, but the log still had AVCs in it and denials that prevented gallery2 and specifically the watermark plugin from working. File and directory permissions were an issue. One of the directories is shared by samba so it has the context of public_content_rw_t.
I used audit2allow to get things working, but I would like someone more knowledgeable than me to take a look as see if I have opened any gaping holes and if so, how to best address the issue.
policy_module(gallery, 1.0) require { type unlabeled_t; type httpd_t; type httpd_tmp_t; type httpd_sys_script_t; type public_content_rw_t; class file { read write unlink }; class dir { write remove_name add_name }; } #============= httpd_sys_script_t ============== allow httpd_sys_script_t unlabeled_t:file { read write };
There shouldn't be any unlabeled files around; the policy should ensure that any files used or created by gallery are labeled properly. If that's done, this rule shouldn't be needed.
allow httpd_sys_script_t file { getattr read };
Not sure about this one. What are the httpd_tmp_t files that gallery is trying to read?
#============= httpd_t ============== allow httpd_t public_content_rw_t:dir { write remove_name
add_name }; allow httpd_t public_content_rw_t:file unlink;
Setting the allow_httpd_anon_write boolean should remove the need for these rules.
Paul.
On Thu, 2007-08-30 at 21:09 +0100, Paul Howarth wrote:
On Thu, 30 Aug 2007 14:56:48 -0400 John Griffiths fedora01@grifent.com wrote:
policy_module(gallery, 1.0) require { type unlabeled_t; type httpd_t; type httpd_tmp_t; type httpd_sys_script_t; type public_content_rw_t; class file { read write unlink }; class dir { write remove_name add_name }; } #============= httpd_sys_script_t ============== allow httpd_sys_script_t unlabeled_t:file { read write };
There shouldn't be any unlabeled files around; the policy should ensure that any files used or created by gallery are labeled properly. If that's done, this rule shouldn't be needed.
Regardless of the correctness of the gellery2 policy unlabeled_t is (almost) always a bug on one kind or another. Did you create some files with selinux completely disabled rather than just permissive? Do you have these files on a filesystem policy knows nothing about (typically a new FUSE filesystem)
Tracking down what files are unlabeled_t and how they got that way is the solution, no rules should allow unlabeled_t
Eric Paris wrote:
On Thu, 2007-08-30 at 21:09 +0100, Paul Howarth wrote:
On Thu, 30 Aug 2007 14:56:48 -0400 John Griffiths fedora01@grifent.com wrote:
policy_module(gallery, 1.0) require { type unlabeled_t; type httpd_t; type httpd_tmp_t; type httpd_sys_script_t; type public_content_rw_t; class file { read write unlink }; class dir { write remove_name add_name }; } #============= httpd_sys_script_t ============== allow httpd_sys_script_t unlabeled_t:file { read write };
There shouldn't be any unlabeled files around; the policy should ensure that any files used or created by gallery are labeled properly. If that's done, this rule shouldn't be needed.
Regardless of the correctness of the gellery2 policy unlabeled_t is (almost) always a bug on one kind or another. Did you create some files with selinux completely disabled rather than just permissive? Do you have these files on a filesystem policy knows nothing about (typically a new FUSE filesystem)
Tracking down what files are unlabeled_t and how they got that way is the solution, no rules should allow unlabeled_t
Thanks. I suspected that was a problem. I'll find the unlabeled_t files and see what they are. Strange though, I had just done a touch /.autorelabel and rebooted a couple of days before.
Regards, John
I tried to use find to find -context *unlabeled_t and it aborted.
find / -context *unlabeled_t *** glibc detected *** find: free(): invalid pointer: 0xbfeca893 *** ======= Backtrace: ========= /lib/libc.so.6[0x47d89a96] /lib/libc.so.6(cfree+0x90)[0x47d8cfb0] /lib/libselinux.so.1(freecon+0x1d)[0x484d87ed] find[0x804fefa] find[0x80503d0] find[0x805038c] find[0x804b8c7] find[0x804bbd0] find[0x804bac0] find[0x804bac0] find[0x804c011] find[0x804aabb] find[0x804ab74] find[0x804b20e] /lib/libc.so.6(__libc_start_main+0xdc)[0x47d38dec] find[0x8049e51] ======= Memory map: ======== 00110000-00111000 r-xp 00110000 00:00 0 [vdso] 08048000-0806c000 r-xp 00000000 fd:00 1818507 /usr/bin/find 0806c000-0806e000 rwxp 00023000 fd:00 1818507 /usr/bin/find 09f1a000-0a052000 rwxp 09f1a000 00:00 0 47d06000-47d1f000 r-xp 00000000 fd:00 4288594 /lib/ld-2.5.so 47d1f000-47d20000 r-xp 00019000 fd:00 4288594 /lib/ld-2.5.so 47d20000-47d21000 rwxp 0001a000 fd:00 4288594 /lib/ld-2.5.so 47d23000-47e5d000 r-xp 00000000 fd:00 4289741 /lib/libc-2.5.so 47e5d000-47e5f000 r-xp 0013a000 fd:00 4289741 /lib/libc-2.5.so 47e5f000-47e60000 rwxp 0013c000 fd:00 4289741 /lib/libc-2.5.so 47e60000-47e63000 rwxp 47e60000 00:00 0 47e8e000-47e90000 r-xp 00000000 fd:00 4289745 /lib/libdl-2.5.so 47e90000-47e91000 r-xp 00001000 fd:00 4289745 /lib/libdl-2.5.so 47e91000-47e92000 rwxp 00002000 fd:00 4289745 /lib/libdl-2.5.so 48115000-48120000 r-xp 00000000 fd:00 4289748 /lib/libgcc_s-4.1.2-20070626.so.1 48120000-48121000 rwxp 0000a000 fd:00 4289748 /lib/libgcc_s-4.1.2-20070626.so.1 48487000-484c2000 r-xp 00000000 fd:00 4289756 /lib/libsepol.so.1 484c2000-484c3000 rwxp 0003b000 fd:00 4289756 /lib/libsepol.so.1 484c3000-484cd000 rwxp 484c3000 00:00 0 484cf000-484e4000 r-xp 00000000 fd:00 4289757 /lib/libselinux.so.1 484e4000-484e6000 rwxp 00015000 fd:00 4289757 /lib/libselinux.so.1 b7c00000-b7c21000 rw-p b7c00000 00:00 0 b7c21000-b7d00000 ---p b7c21000 00:00 0 b7d3b000-b7f3b000 r--p 00000000 fd:00 1814079 /usr/lib/locale/locale-archive b7f3b000-b7f3d000 rw-p b7f3b000 00:00 0 b7f4e000-b7f55000 r--s 00000000 fd:00 1866355 /usr/lib/gconv/gconv-modules.cache bfeb8000-bfece000 rw-p bfeb8000 00:00 0 [stack] Aborted
Bug?
Regards, John Griffiths
selinux@lists.fedoraproject.org