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
