Red Hat Bugzilla – Bug 175557
Handle RPMs containing DSOs with text relocations better
Last modified: 2015-03-20 07:22:26 EDT
Description of problem:
The SELinux policy now enforces the EXECMOD rules which prevent a program to
make a memory region mapped from disk executable if it was writable before. But
this is exactly what is needed to make DSOs with text relocations usable. Text
relocation are a plague on x86 and some other archs which we only slowly get rid of.
Int theory this could be resolved by adding all kinds of DSOs to the policy.
But this has disadvantages:
- when to remove them? When the DSOs are fixed (or the tools used to build
them) the permissions should be removed
- what about 3rd party RPMs? The execmod rules affect unconfined binaries as well.
One proposed solution (by Stephen Smalley) is to have rpm examine DSOs for text
relocations. If a DSO with a text relocation is found it should add the path
name with a rule to change the context to
to the file file_contexts.local in the policy directory. If no text relocation
is found, rpm should make sure the path name is not listed in that file.
This solution would have to address the issue and doesn't have any of the
mentioned drawbacks. Especially 3rd party rpm packages just work.
Ideally I would like an option for rpm to disable this behavior, for the
security conscious sysadmin.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.use firefox on a FC rawhide system today, with today's SELinux policy
FYI: SELinux support is headed out of rpm because there is
essentially no communication between different devel efforts,
and SELinux and rpm have drastically different goals.
Why can't SELinux figure out how to write
to the file file_contexts.local?
Don't almost all DSO's have text relocations? Perhaps the problem is
easier to solve for the handful of DSO's that don't have text relocations.
> Why can't SELinux figure out how to write [...]
This makes no sense, there is no SELinux program which can figure something out.
ALl changes to security contexts must be initiated by somebody. One could have
cron jobs going over the entire filesystem space every minute to detect new
files but this is insane. The context must be set correctly at installation
time and this means rpm.
> Don't almost all DSO's have text relocations?
Hell, no. Almost none has and the recent policy changes will hpefully abolish
almost all the remaining ones.
I won't comment on the first paragraph since I have no idea what "rpm" you're
talking about. The rpm in Red Hat's distributions definitely needs SELinux
support and this request is solely directed to the rpm Red Hat ships. I could
not possibly care less about the "upstream" version.
I don't know about communication breakdowns between rpm devel and SELinux devel
folks; if we've erred, let us know and we'll try to improve. Doesn't help to
carp about it in a bugzilla entry that few people will ever see. Wandering over
to the rpm devel list archives, I see that you've proposed further separation
there, but I'm not clear that will actually help - ultimately, package
management has to be aware of and properly integrated with SELinux, and making
it easier for us to break one another without coordination doesn't seem to help.
On this particular issue, rpm currently handles setting the security context on
files when they are installed from packages, so it seems to make sense for rpm
to invoke some functionality for checking whether a DSO it is about to install
has text relocations and to then invoke some SELinux function (likely some new
libsemanage interface) with the file's installation pathname and the result of
the text relocation test so that the file contexts configuration can be updated
properly. Then when rpm calls matchpathcon to get the context to apply to the
installed file, it will get the proper context, and any subsequent restorecon,
setfiles, etc runs will properly preserve it. The details of updating
file_contexts.local would be encapsulated in some SELinux function, as you suggest.
The issue is tying package management to dynamic configuration. this leads to hard QA
and many erroneous bug reports, mostly due to slowly changing policy deploy.
Adding New Stuff (like this RFE) creates instant (and difficult) legacy. rpm essentially
cannot be upgraded because noone is making the effort, and no vendor is willing to
undertake the retrofit.
So all I can see is to freeze in the existing hooks, and split out into a dlopen package that
might be changed more rapidly than rpm is.
Meanwhile -- if you wish my help -- firstname.lastname@example.org is the place, as clearly
this is Red Hat's, not rpm's, bugzilla now.
And for Yet Another Conundrum, /bin/rpm is now statically linked again again again, so dlopen
of libselinux appears only viable approach other than reverting to dynamically linked.
... if there is still interest in this bug, libsemanage now has the capability
of adding new file contexts programmatically (semanage/fcontext_*.h). An
semanage transaction is rather slow, so the way to handle this is to start a
transaction, deal with all relocations for multiple rpms, then commit (not per
There certainly is the need to do this. There will always be code with text
relocations on some systems, regardless of how hard we try to remove them.
Proprietary software (including the nvidia GL libraries) are beyond our control
but have text relocs.
So, adding this code certainly makes sense.
The issue is adding the code to rpm, not whether there is a need to add code to support a given
NEEDINFO_ENG so I don't have to stare at the bug.
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.
The right way to fix this problem (per my sense of discussion w smalley and drepper @ OLS) is
for rpm to provide the infomation that a file has text relocations to libselinux so that a different
security context can be attached to the file.
Some means of passing the information to libselinux needs to be devised.
The wrong way to fix this problem is to have rpm with a compiled in rule to change what contexts that
User email@example.com's account has been closed
Reassigning to owner after bugzilla made a mess, sorry about the noise...
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This is ancient! Does anyone still care? Does the problem even exist any more? Please reopen if that's the case.