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?
Thanks, Chuck
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:
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----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
On Mon, Jun 06, 2011 at 11:31:15AM -0400, Daniel J Walsh wrote:
- Preferably get rid of the text relocations.
+10000000
I've been in contact with the upstream author, and he is working towards that goal.
In the meantime, I've compiled the C version which does use -fPIC (and happens to avoid some other bugs with the assembly version)
https://admin.fedoraproject.org/updates/ocp-0.1.20-8.fc15 https://admin.fedoraproject.org/updates/ocp-0.1.20-8.fc14 https://admin.fedoraproject.org/updates/ocp-0.1.20-8.fc13
Karma appreciated :-)
- If that is not possible then ask selinux-policy to add file context
specs for the libs that need it.
Yes
In this case, I would like to ask that the selinux-policy package remove this obsolete file context and not replace it with anything else:
/usr/lib(64)?/ocp-.*/mixclip.so -- system_u:object_r:textrel_shlib_t:s0
Should I file a bug against selinux-policy?
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
I've decided to use this method for the temporary need of textrel_shlib_t on the assembly version (which can be built by using --with-i386asm, but is not built this way by default in Fedora). That way I can easily remove this later when text relocations are no longer needed (and I can switch back to the assembly version).
Thanks for the input.
Regards to all the list I was reading the SELinux Notebook and I saw that the rpm packages are for Fedora 12. Where I can find the packages for Red Hat? Which is the repository?
Thanks for your time
On Thu, 2011-06-09 at 10:10 -0430, Marcos Ortiz wrote:
Where I can find the packages for Red Hat? Which is the repository?
If you mean Red Hat Enterprise Linux then you would need a subscription to be able to get the compiled policy via the Red Hat Network i believe.
You can get the sources on the Red Hat FTP site (ftp.redhat.com)
On 06/04/2011 03:13 AM, 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.
Open a new bug with these locations on selinux-policy component.
- 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?
Thanks, Chuck -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org
-
Chuck Anderson -
Daniel J Walsh -
Dominick Grift -
Marcos Ortiz Valmaseda -
Miroslav Grepl