On Tue, 19 Jun 2007, Jon Peatfield wrote:

[...]
>> 	chcon -t texrel_shlib_t .../_librsync.so
>
> Very few things seem to have that context by default.  Certainly none of the 
> libs in /lib seem to...

Very few require it...

NB there was a type in may mail: it's "textrel_shlib_t"

>  $ ls -ldZ /lib/lib*.so| grep shlib_t | wc -l
>  0
>
> is this a flaw in my installation or are those .so files treated differently 
> for some reason?  Or do those simply not need it?

Libraries needing this can't deal with a restriction that should be 
imposed on any and all processes today: after relocation, memory should be 
either writable or executable, not both. If this is enforced, many 
exploits of programming errors (buffer overflows) simply won't work: 
Arbitrary code can no longer be executed on a victim's system. You can 
still manipulate a programme's data, and it may be possible to make it 
behave the way you want this way, but that's typically much harder, a 
whole class of attacks simply becomes a non-issue. (This is already 
relaxed: for example, executable stacks are still allowed by default since 
too much software would break if they weren't).

In addition, some say that shared objects requiring text relocations are 
simply broken. See  http://people.redhat.com/~drepper/textrelocs.html :

    "A text relocation is the result of a reference to an object with a
    variable address at runtime using an absolute addressing mode. The
    instruction encoding itself contains the address and therefore the
    executable text of the binary must be changed to contain the correct
    address when taking the actual load addresses at runtime into account.

    The result of a text relocation is that the binary text is written to.
    This means this page of the binary cannot be physically shared with
    other processes on the system (this is the goal of DSOs, aka shared
    libraries). It also means that the binary must have permission to
    change the access permissions for the memory page to include writing
    and then back to executing. This is a privileged operation when SELinux
    is enabled."

The usual fix seems to be to recompile any code meant to go 
into a shared object with -fPIC, and the usual culprit seems to be that 
objects from static libs, not compiled to be position independent, are 
drawn into shared objects.

Apparently, this only works on very few platforms anyway, and 
unfortunately Linux on i386 is one of them. It's one of the things making 
migration to x86_64 (and other 64-bit platforms) harder than it should be.

> If that should be the right context should the package (or restorecon?) set 
> that automatically?

Since this is an add-on package, restorecon can hardly be blamed. Seems 
like the package wasn't tested with SELinux in effect. Otherwise, the 
packager could have fixed the code or the build, or added a %post or a 
policy module.

> How should one make this kind of thing work for (e.g.) user-installed python 
> modules over NFS (ie without context support) or other things which need 
> similar magic?

You don't. You use software coded and built according to these 
restrictions, or install it on a filesystem supporting xattrs and relabel 
it, or you run your systems without the extra protection provided by 
SELinux.

Yes, it's causing us headaches as well. We're not willing to give it up 
yet, though.

Cheers,
 	Stephan

-- 
Stephan Wiesand
   DESY - DV -
   Platanenallee 6
   15738 Zeuthen, Germany