Transitions for files.

[Vadym Chepkov]

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

[Daniel J Walsh]

-----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(a)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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAky8XzEACgkQrlYvE4MpobNr8ACghvKz51f7VjBlurlDuCozML2W
> vbYAnj8jKm0t6ggLEe2EyjLvt7cRtUwr
> =1BrC
> -----END PGP SIGNATURE-----

[Vadym Chepkov]

On Mon, Oct 18, 2010 at 10:52 AM, Daniel J Walsh <dwalsh(a)redhat.com&gt; 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

[Daniel J Walsh]

-----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(a)redhat.com&gt; 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(a)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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAky8ZmsACgkQrlYvE4MpobNP1QCg4dXRGdCXfajjpOssCNMjkTSL
> l7cAn0Fa2IVSeYD4jA9kzZGoci50SsKP
> =LuHc
> -----END PGP SIGNATURE-----

[Miroslav Grepl]

  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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Vadym Chepkov]

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

[Miroslav Grepl]

  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
>
>
>
>

[Vadym Chepkov]

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

[Miroslav Grepl]

  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
>
>
>
>

[Vadym Chepkov]

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
> > 
> > 
> > 
> > 
>

[Miroslav Grepl]

  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
> >>
> >>
> >>
> >>

[Vadym Chepkov]

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