+++ This bug was initially created as a clone of Bug #1602914 +++ Description of problem: When elfutils-default-yama-scope happens to be upgraded in container, AVC denial about container_t and sysctl_kernel_t. Version-Release number of selected component (if applicable): On host: container-selinux-2:2.65-1.gitbf5b26b.fc28.noarch In container: elfutils-default-yama-scope-0.170-11.fc29.noarch How reproducible: Deterministic. Steps to Reproduce: 1. docker run --rm registry.fedoraproject.org/fedora:rawhide dnf upgrade -y elfutils-default-yama-scope 2. Check audit.log Actual results: Unable to find image 'registry.fedoraproject.org/fedora:rawhide' locally Trying to pull repository registry.fedoraproject.org/fedora ... sha256:521225b1a14aba45bdbce042f42f2f457813b0fdd58989325a7fa5321a223387: Pulling from registry.fedoraproject.org/fedora f5b598b9ce0d: Pulling fs layer f5b598b9ce0d: Verifying Checksum f5b598b9ce0d: Download complete f5b598b9ce0d: Pull complete Digest: sha256:521225b1a14aba45bdbce042f42f2f457813b0fdd58989325a7fa5321a223387 Status: Downloaded newer image for registry.fedoraproject.org/fedora:rawhide MARK-LWD-LOOP -- 2018-07-18 15:24:57 -- Fedora - Rawhide - Developmental packages for t 427 kB/s | 62 MB 02:27 Last metadata expiration check: 0:01:02 ago on Wed Jul 18 19:26:35 2018. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Upgrading: elfutils-default-yama-scope noarch 0.173-2.fc29 rawhide 14 k Transaction Summary ================================================================================ Upgrade 1 Package Total download size: 14 k Downloading Packages: elfutils-default-yama-scope-0.173-2.fc29.noarch 60 kB/s | 14 kB 00:00 -------------------------------------------------------------------------------- Total 13 kB/s | 14 kB 00:01 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Upgrading : elfutils-default-yama-scope-0.173-2.fc29.noarch 1/2 Running scriptlet: elfutils-default-yama-scope-0.173-2.fc29.noarch 1/2 Cleanup : elfutils-default-yama-scope-0.170-11.fc29.noarch 2/2 Running scriptlet: elfutils-default-yama-scope-0.170-11.fc29.noarch 2/2 Verifying : elfutils-default-yama-scope-0.173-2.fc29.noarch 1/2 Verifying : elfutils-default-yama-scope-0.170-11.fc29.noarch 2/2 Upgraded: elfutils-default-yama-scope.noarch 0.173-2.fc29 Complete! and type=AVC msg=audit(1531942069.455:173): avc: denied { write } for pid=14418 comm="systemd-sysctl" name="ptrace_scope" dev="proc" ino=48216 scontext=system_u:system_r:container_t:s0:c162,c763 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file permissive=0 Expected results: No AVC denial. Additional info: Scriptlet in elfutils-default-yama-scope does /usr/lib/systemd/systemd-sysctl 10-default-yama-scope.conf >/dev/null 2>&1 || : and /usr/lib/sysctl.d/10-default-yama-scope.conf contains kernel.yama.ptrace_scope = 0 --- Additional comment from Jan Pazdziora on 2018-07-18 21:52:08 CEST --- I guess this is reproducer for bug 1435868. --- Additional comment from Daniel Walsh on 2018-07-18 22:41:58 CEST --- Are these properly namespaced? --- Additional comment from Jan Pazdziora on 2018-07-18 23:23:00 CEST --- I have no idea. I'm merely external observer here. --- Additional comment from Daniel Walsh on 2018-07-25 23:27:15 CEST --- Ok so this is also mounted readonly, so I think I will just add a dontaudit rule. --- Additional comment from Daniel Walsh on 2018-07-25 23:35:55 CEST --- Fixed in container-selinux-2.69-1.git452b90d --- Additional comment from Fedora Update System on 2018-07-26 13:52:50 CEST --- container-selinux-2.69-1.git452b90d.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-42991b7a1d --- Additional comment from Frank Ch. Eigler on 2018-07-26 15:38:14 CEST --- It seems to me that elfutils' %post should not attempt to run this sysctl at all, and just leave it to the next reboot. That would also solve this problem (since a container startup wouldn't trigger this). --- Additional comment from Fedora Update System on 2018-07-26 18:34:03 CEST --- container-selinux-2.69-1.git452b90d.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-42991b7a1d
Based on Frank's suggestion in bug 1602914 comment 8, filing also against elfutils for consideration.
It looks like this issue is already resolved in container-selinux. If there still is an issue I think this is an issue for systemd. All elfutils does is run the normal %sysctl_apply macro in %post, which uses systemd-sysctl. So if that should do something different to activate the sysctl setting inside a container then it probably should be change/fixed in systemd.
I think Frank's point way: should elfutils-default-yama-scope run that systemd-sysctl in runtime, rather than letting it on reboot?
(In reply to Jan Pazdziora from comment #3) > I think Frank's point way: should elfutils-default-yama-scope run that > systemd-sysctl in runtime, rather than letting it on reboot? Yes it should. That is the way to activate the new sysctl setting. so that no reboot is necessary: https://fedoraproject.org/wiki/Packaging:Guidelines#binfmt.d.2C_sysctl.d_and_tmpfiles.d That is why I think this really is a systemd issue. If something else is necessary in an container install then systemd-sysctl should do the right thing.
Let's reassign to systemd for their consideration, since that sysctl_apply rpm macro comes from systemd, and runs /usr/lib/systemd/systemd-sysctl. ISTM that the intent of this fedora guideline is not appropriate when an installation is done in the context of a container image construction, since sysctl's are moot / disabled / error-generating in that context.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
It'd be good to get some opinion from systemd maintainers.
It seems we should probably make the macro do nothing when run in a container. Let me discuss this with other maintainers.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #8) > It seems we should probably make the macro do nothing when run in a > container. > Let me discuss this with other maintainers. Was there some result from that discussion?
We discussed this upstream. A PR [1] was submitted to "downgrade" the log message when we cannot write a sysctl from log_notice to log_debug. This means that it will not be shown by default (the default log level is info). sysctl should still be run in containers, because some settings might be writable in containers, in particular for network-related settings this is pretty common. As for any spurious selinux warnings, selinux should just not emit them. Please talk to the policy maintainers about this. [1] https://github.com/systemd/systemd/pull/14585
I thought the SELinux part was addressed in bug 1602914 quite some time ago and this bugzilla was about the sysctl_apply rpm macro. In container image build time when the majority of the rpm operations in containers happen, you never want the sysctl run or propagated.
> I thought the SELinux part was addressed in bug 1602914 quite some time ago Oh, right. > In container image build time when the majority of the rpm operations in containers happen, you never want the sysctl run or propagated. /proc/sys should be protected in the container so that the container does not have access to settings it shouldn't have. systemd-sysctl ignores the access failure. The only change with the linked PR is to avoid a warning. OK, so this should be all OK once the PR goes in.
This is fixed in F31 now, but the patch has a lot of conflicts, so I don't want to backport it to F30. Sorry.