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:
1. 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.
2. 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)
3. 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
4. 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?
5. 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?
6. 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:
1. Preferably get rid of the text relocations.
2. If that is not possible then ask selinux-policy to add file context
specs for the libs that need it.
3. 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.
Thanks,
Chuck
--
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux