-----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: >> >> 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. > +10000000 > 2. If that is not possible then ask selinux-policy to add file context > specs for the libs that need it. > Yes > 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. > 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@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/selinux >> >> >> -- >> selinux mailing list >> selinux@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/selinux -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3s8sMACgkQrlYvE4MpobOyfgCgzx4skh/ab7XT4tv9zqT3S/8S jpIAoKZb75ac77DRREAzI6tEVTA/Mt0e =0omo -----END PGP SIGNATURE----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
