-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/04/2011 11:09 AM, Dominick Grift wrote:
On Fri, 2011-06-03 at 23:13 -0400, Chuck Anderson wrote:
I'm the package maintainer for ocp (Open Cubic Player) in Fedora. The 32-bit i386 version of ocp has hand-written assembly code that can't be compiled with -fPIC, and requires text relocations to run. The x86_64 (and all other architectures) version uses C code for the same functions, and so does not need text relocations. I'm also investigating a way to compile the 32-bit version with the C functions instead of the optimized non-PIC assembly. The bug is here:
https://bugzilla.redhat.com/show_bug.cgi?id=470949
I also found this bug which I was never informed of at the time it was filed and fixed by applying textrel_shlib_t for mixclip.so in the selinux-policy package (which incidentally won't work anymore since mixclip.so moved in newer versions of ocp):
https://bugzilla.redhat.com/show_bug.cgi?id=550252
sudo grep ocp /etc/selinux/targeted/contexts/files/file_contexts
/usr/lib(64)?/ocp-.*/mixclip.so -- system_u:object_r:textrel_shlib_t:s0
(This tripped me up for a while since I couldn't figure out why semange fcontext -d couldn't delete this--until I realized I hadn't added this with semanage--it was in the selinux-policy package.)
Here are the current files that require text relocations if I'm interpreting the output of eu-findtextrel correctly (again, only i386 32-bit):
eu-findtextrel /usr/lib/ocp-*/{*,autoload/*} | & grep -v 'no text reloc' | cut -d: -f1 | sort -u
eu-findtextrel /usr/lib/ocp-0.1.20/autoload/10-mixclip.so /usr/lib/ocp-0.1.20/autoload/30-mcpbase.so /usr/lib/ocp-0.1.20/devwmixf.so /usr/lib/ocp-0.1.20/devwmix.so
My questions are:
- Should you add these to selinux-policy (and remove the previous obsolete entry)?
/usr/lib/ocp-.*/(autoload/)?.*devwmix.so -- system_u:object_r:textrel_shlib_t:s0 /usr/lib/ocp-.*/(autoload/)?.*devwmixf.so -- system_u:object_r:textrel_shlib_t:s0 /usr/lib/ocp-.*/(autoload/)?.*mcpbase.so -- system_u:object_r:textrel_shlib_t:s0 /usr/lib/ocp-.*/(autoload/)?.*mixclip.so -- system_u:object_r:textrel_shlib_t:s0
This should cover all known variations in location.
- Or, should I add this to my package %post (and have you remove the obsolete entry):
%ifarch %{ix86} semanage fcontext -a -t textrel_shlib_t '%{_libdir}/ocp-.*/(autoload/)?.*devmix.so' 2>/dev/null || : semanage fcontext -a -t textrel_shlib_t '%{_libdir}/ocp-.*/(autoload/)?.*devmixf.so' 2>/dev/null || : semanage fcontext -a -t textrel_shlib_t '%{_libdir}/ocp-.*/(autoload/)?.*mcpbase.so' 2>/dev/null || : semanage fcontext -a -t textrel_shlib_t '%{_libdir}/ocp-.*/(autoload/)?.*mixclip.so' 2>/dev/null || : restorecon -R %{_libdir}/ocp-.* || : %endif
(as http://fedoraproject.org/wiki/PackagingDrafts/SELinux recommends, but this is still a draft guideline)
- Or, should I cover all bases for current and possible future needs
with a more permissive match (what is the security risk here?):
%ifarch %{ix86} semanage fcontext -a -t textrel_shlib_t '%{_libdir}/ocp-.*/(autoload/)?.*.so' 2>/dev/null || : restorecon -R %{_libdir}/ocp-.* || : %endif
- Or, should I find a way to compile with -fPIC (possibly reverting
to the C versions instead of assembly) so I don't need text relocations? How much of a security risk is giving textrel_shlib_t to these libraries?
- I noticed that the various allow_exec* booleans changed their
default values in successive Fedora versions:
Fedora 13 i386:
allow_execheap --> off allow_execmem --> on allow_execmod --> off allow_execstack --> on
Fedora 14 i386:
allow_execheap --> off allow_execmem --> on allow_execmod --> on allow_execstack --> off
Fedora 15 i386:
allow_execheap --> off allow_execmem --> on allow_execmod --> on allow_execstack --> on
What's the history here? Things seem to be moving in a more permissive direction--so I guess the convenience of allowing these was deemed worth the security risk of having them on by default?
- Should I do nothing and just rely on the default boolean values in
Fedora 14 and newer to allow people to run ocp on i386?
Disclaimer: My personal view on this:
- Preferably get rid of the text relocations.
+10000000
- If that is not possible then ask selinux-policy to add file context
specs for the libs that need it.
Yes
- Unconfined users should probably be unconfined. If unconfined is not
unconfined then what is? So in that light the booleans should probably be on by default in my view. Those booleans only apply to unconfined_t (or at least that was the initial design i believe) The security is worth it but the unconfined domain is (or should be in my view) exempted.
Well we are now moving to this, it does not help if a confined app uses the shared library. Say apache.
textrel_shlib_t usually means the developer of the library made a mistake, and we want to cover up for it by making SELinux be quite and just allow it.
If you want to set the label in the post install you should execute the semanage command.
semanage fcontex -a -t textrel_shlib_t PATHTOSHLIB restorecon PATHTOSHLIB
Thanks, Chuck -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux