Bug 175557 - Handle RPMs containing DSOs with text relocations better
Handle RPMs containing DSOs with text relocations better
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Fedora Packaging Toolset Team
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-12 14:09 EST by Ulrich Drepper
Modified: 2015-03-20 07:22 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-20 07:22:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ulrich Drepper 2005-12-12 14:09:24 EST
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

  system_u:object_r:texrel_shlib_t

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):


How reproducible:


Steps to Reproduce:
1.use firefox on a FC rawhide system today, with today's SELinux policy
2.
3.
  
Actual results:
execmod complaints

Expected results:
runs

Additional info:
Comment 1 Jeff Johnson 2005-12-12 14:52:47 EST
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
    system_u:object_r:texrel_shlib_t
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.
Comment 2 Ulrich Drepper 2005-12-12 15:29:00 EST
> 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.
Comment 3 Stephen Smalley 2005-12-12 15:42:36 EST
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.

  
Comment 4 Jeff Johnson 2005-12-12 18:26:59 EST
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 -- rpm-devel@lists.dulug.duke.edu is the place, as clearly
this is Red Hat's, not rpm's, bugzilla now.
Comment 5 Jeff Johnson 2005-12-12 18:31:59 EST
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.
Comment 6 Ivan Gyurdiev 2006-01-12 16:05:00 EST
... 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
rpm). 
Comment 7 Ulrich Drepper 2006-01-13 02:39:02 EST
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.
Comment 8 Jeff Johnson 2006-01-20 15:00:24 EST
The issue is adding the code to rpm, not whether there is a need to add code to support a given 
functionality.

NEEDINFO_ENG so I don't have to stare at the bug.
Comment 9 David Lawrence 2006-04-18 16:11:27 EDT
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.
Comment 10 Jeff Johnson 2006-07-29 13:48:58 EDT
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
libselinux returns.
Comment 11 Red Hat Bugzilla 2007-08-21 01:21:42 EDT
User pnasrat@redhat.com's account has been closed
Comment 12 Panu Matilainen 2007-08-22 02:30:49 EDT
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Comment 13 Fedora Admin XMLRPC Client 2012-04-13 19:11:59 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 14 Fedora Admin XMLRPC Client 2012-04-13 19:13:55 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 15 Florian Festi 2015-03-20 07:22:26 EDT
This is ancient! Does anyone still care? Does the problem even exist any more? Please reopen if that's the case.

Note You need to log in before you can comment on or make changes to this bug.