Bug 1250079 - Provide default-yama-scope to unbreak elfutils-libs and tools
Provide default-yama-scope to unbreak elfutils-libs and tools
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: elfutils (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Mark Wielaard
Fedora Extras Quality Assurance
:
Depends On: 1209492
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-04 09:24 EDT by Mark Wielaard
Modified: 2015-08-17 18:24 EDT (History)
10 users (show)

See Also:
Fixed In Version: elfutils-0.163-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-17 18:24:58 EDT
Type: Bug
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 Mark Wielaard 2015-08-04 09:24:51 EDT
Recent kernels have enabled yama but without setting the ptrace_scope sysctl to the default security setting (0). The "restricted ptrace" breaks elfutils tools and elfutils-libs. See bug #1209492

Provide a default-yama-scope package to unbreak elfutils tools and libs and that can be used to unbreak other packages by simply Require: default-yama-scope.
Comment 1 Mark Wielaard 2015-08-04 09:25:33 EDT
Proposed upstream patch:
https://lists.fedorahosted.org/pipermail/elfutils-devel/2015-August/005079.html
Comment 2 Mark Wielaard 2015-08-04 10:13:22 EDT
New package with above patch applied now available in rawhide.
http://koji.fedoraproject.org/koji/taskinfo?taskID=10600439
Will backport to f22 after some testing.
Comment 3 Paul Moore 2015-08-04 10:40:59 EDT
Please see BZ 1209492#c74, I think we should ship a "yama-config-disable" as a independent package, not as part of elfutils or any other package.
Comment 4 Mark Wielaard 2015-08-04 11:24:11 EDT
(In reply to Paul Moore from comment #3)
> Please see BZ 1209492#c74, I think we should ship a "yama-config-disable" as
> a independent package, not as part of elfutils or any other package.

I replied there. I don't think that is necessary. Lets just test the current package in rawhide and then provide it for f22 once it works as expected.
Comment 5 Paul Moore 2015-08-04 12:21:28 EDT
I strongly disagree, see my comments in BZ #1209492
Comment 6 Miloslav Trmač 2015-08-17 17:34:13 EDT
Silently changing system-wide security policy as an additional dependency of an effectively mandatory package (systemd-libs requires: elfutils-libs) in the middle of F22 lifetime is a _really_ bad idea.

I appreciate that you your package to “just work” but this is not a reasonable way to go about it.  Either the kernel functionality change was an ABI breakage unwanted at the time, that should be fixed in the kernel, or it was an acceptable thing to change in F22, and then it is unacceptable to silently open up access against possible wishes of administrators who thought they were protected.
Comment 7 Simo Sorce 2015-08-17 17:40:52 EDT
Reverting the kernel configuration would be a much more appropriate fix for F22, and I guess F23 too at this point. User space need to be ready for something like this *before* you make the kernel enforce stricter ptrace control.

Papering over it with a config file delivered via a new rpm package seem like a very cumbersome way to go about it.
Comment 8 Frank Ch. Eigler 2015-08-17 17:42:28 EDT
Simo, I agree, but absent other options (FESCO involvement to request the kernel revert), this seemed the least bad way.
Comment 9 Mark Wielaard 2015-08-17 18:24:58 EDT
I certainly also agree there were different ways to fix this. My personal preference would also have been to directly fix this in the kernel package. And if you read the original bug report (bug #1209492) you'll see several other suggestions for fixes. In the end the consensus was that having a separate package to provide a default-yama-config that packages that need it depend on was seen as the best solution. I don't believe anybody is really enthusiastic about it. But given all other options were considered worse, or unacceptable, this is what we got. Comments and better suggestions on the original bug #1209492 certainly welcome.

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