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:
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.
> 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 -- rpm-devel.duke.edu 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 rpm).
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 functionality. 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 libselinux returns.
User pnasrat'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.