I found some interesting things about this bug.

In my machine, with SELinux fully enabled (and without any modifications), I can manually execute /usr/lib/systemd/systemd-sysctl (i.e., not restart the service, but call the program directly from the command line), and it *successfully* does its job.  No SELinux errors, nothing.  However, I can reproduce the bug reported by Mark when I issue a "systemctl restart systemd-sysctl.service" (i.e., SELinux gives me a no-no and systemd-sysctl does not update the ptrace_scope file under /proc).

FWIW, this is the reason why the %sysctl_apply macro works fine when you install a RPM which performs this modification on ptrace_scope: the macro actually executes /usr/lib/systemd/systemd-sysctl directly, and don't restart the service.  However, the user will be affected in the next reboot because the service will be started on the boot, leading to the SELinux error.

(In reply to Sergio Durigan Junior from comment #1)
> I found some interesting things about this bug.

Nice find! Indeed just running:
$ sudo /usr/lib/systemd/systemd-sysct
works fine, without selinux errors and sets the sysctl value as expected.
But running:
$ sudo systemctl restart systemd-sysctl.service
gives selinux errors and doesn't set the sysctl value.

That is strange, The /usr/lib/systemd/system/systemd-sysctl.service file looks very simple:

[Unit]
Description=Apply Kernel Variables
Documentation=man:systemd-sysctl.service(8) man:sysctl.d(5)
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-modules-load.service
Before=sysinit.target shutdown.target
ConditionPathIsReadWrite=/proc/sys/

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-sysctl

What is also strange is that for me it depends on which kernel I boot into whether or not the sysctl value is set. With 4.1.4-200 the value isn't set. But when I boot into 4.1.5-200 the value is set. Even though in both cases systemctl status systemd-sysctl shows the service failed.... strange.

BTW. The workaround suggested in the selinux alert message:
# grep systemd-sysctl /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Works fine in all cases. No more errors are generated and the sysctl value is always set correctly.

The following explains why systemd-sysctl seems to just work fine when run by hand or through rpm, dnf, etc. but not when run through systemctrl. In the first case it runs unconfined, but in the second case it transitions to systemd_sysctl_t and so gets blocked by selinux when it is missing a permission to set a sysctl value:
http://danwalsh.livejournal.com/23944.html
https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl

This is also occurring in F23a. Manually calling the command works as well. The Selinux workaround generated in the alert message fixes the issue.

Description of problem:
Just booted up the system

Version-Release number of selected component:
selinux-policy-3.13.1-128.8.fc22.noarch

Additional info:
reporter:       libreport-2.6.2
hashmarkername: setroubleshoot
kernel:         4.1.5-200.fc22.x86_64
type:           libreport

Could you attach all AVC's. sys_ptrace capability is usually not needed.  It can be caused just by lookin in /proc.  Want to make sure that is the only breakage.

(In reply to Daniel Walsh from comment #7)
> Could you attach all AVC's.

There is only one:

$ sudo grep -i avc /var/log/audit/audit.log
type=AVC msg=audit(1439907280.909:528): avc:  denied  { sys_ptrace } for  pid=3407 comm="systemd-sysctl" capability=19  scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:system_r:systemd_sysctl_t:s0 tclass=capability permissive=0

# rpm -q systemd elfutils-default-yama-scope; uname -r
systemd-219-21.fc22.x86_64
elfutils-default-yama-scope-0.163-3.fc22.noarch
4.1.4-200.fc22.x86_64

# systemctl restart systemd-sysctl.service
Job for systemd-sysctl.service failed. See "systemctl status systemd-sysctl.service" and "journalctl -xe" for details.

# journalctl --since "1m ago"
systemd[1]: Starting Apply Kernel Variables...
audit[4591]: <audit-1400> avc:  denied  { sys_ptrace } for  pid=4591 comm="systemd-sysctl" capability=19  scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=system_u:system_r:systemd_sysctl_t:s0 tclass=capability permissive=0
systemd-sysctl[4591]: Failed to write '0' to '/proc/sys/kernel/yama/ptrace_scope': Operation not permitted
systemd[1]: systemd-sysctl.service: main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Apply Kernel Variables.
systemd[1]: Unit systemd-sysctl.service entered failed state.
systemd[1]: systemd-sysctl.service failed.
audit[1]: <audit-1130> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-sysctl comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
setroubleshoot[4528]: SELinux is preventing systemd-sysctl from using the sys_ptrace capability. For complete SELinux messages. run sealert -l 85f55b09-c67c-4a3e-beda-36b467349d1b

Description of problem:
I noticed that kernel variables were not loaded during boot. I've checked "systemctl status systemd-sysctl" and it had failed.When I tried "systemctl start systemd-sysctl" an AVC denial warning showed up.

Version-Release number of selected component:
selinux-policy-3.13.1-128.10.fc22.noarch

Additional info:
reporter:       libreport-2.6.2
hashmarkername: setroubleshoot
kernel:         4.1.5-200.fc22.x86_64
type:           libreport

Ok I guess we need to add it. Could you build a custom policy and see if this fixes the problem.


# ausearch -m avc -ts today | audit2allow -M mypol
# semodule -i mypol.pp

(In reply to Daniel Walsh from comment #11)
> Ok I guess we need to add it. Could you build a custom policy and see if
> this fixes the problem.
> 
> # ausearch -m avc -ts today | audit2allow -M mypol
> # semodule -i mypol.pp

Yes, that fixes the issue.

For the record the generated policy was:

#============= systemd_sysctl_t ==============
allow systemd_sysctl_t self:capability sys_ptrace;

*** Bug 1253969 has been marked as a duplicate of this bug. ***

Description of problem:
# systemctl start systemd-sysctl
Job for systemd-sysctl.service failed. See "systemctl status systemd-sysctl.service" and "journalctl -xe" for details.

Version-Release number of selected component:
selinux-policy-3.13.1-128.10.fc22.noarch

Additional info:
reporter:       libreport-2.6.2
hashmarkername: setroubleshoot
kernel:         4.1.5-200.fc22.x86_64
type:           libreport

Description of problem:
Started with kernel update 4.1.5

Version-Release number of selected component:
selinux-policy-3.13.1-128.10.fc22.noarch

Additional info:
reporter:       libreport-2.6.2
hashmarkername: setroubleshoot
kernel:         4.1.6-200.fc22.x86_64
type:           libreport

Dan, I agree.

Service with this rule started normally.

commit c2c8beb2ab81529612bafac5d4e65ecfbe70068d
Author: Lukas Vrabec <lvrabec>
Date:   Sun Aug 23 18:12:17 2015 +0200

    Allow systemd-sysctl cap. sys_ptrace  BZ(1253926)

*** Bug 1255980 has been marked as a duplicate of this bug. ***

selinux-policy-3.13.1-128.12.fc22 has been submitted as an update to Fedora 22. https://bugzilla.redhat.com/show_bug.cgi?id=1253926

*** Bug 1256334 has been marked as a duplicate of this bug. ***

The same problem appears in F23, selinux-policy-3.13.1-141.fc23.  Will that also get fixed as part of this, or do you want a separate Bugzilla about that?

selinux-policy-3.13.1-128.12.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14076

Hi Göran,
This will be fixed in selinux-policy-3.13.1-144.fc23

Description of problem:
On a default Fedora 22 installation, I get an error on boot "Failed to start Apply Kernel Variables. See 'sysctl status systemd-sysctl.service' for details". 

When I tried manually starting the service with "systemctl start systemd-sysctl.service", the SELinux Troubleshooter app appeared saying the service did not have permissions for 'sys_ptrace' capability. I ran the recommended fix of "grep systemd-sysctl /var/log/audit/audit.log | audit2allow -M mypol && semodule -i mypol.pp" and was able to successfully start the service. I believe this permission should be part of the default SELinux policy.

Version-Release number of selected component:
selinux-policy-3.13.1-128.10.fc22.noarch

Additional info:
reporter:       libreport-2.6.2
hashmarkername: setroubleshoot
kernel:         4.1.3-201.fc22.x86_64
type:           libreport

Hi Lukas,
I am wondering if the update selinux-policy-3.13.1-144.fc23 will be made available for F22?

selinux-policy-3.13.1-128.12.fc22 has been released, once you get the update, it should fix the issue. You can also go here to download the RPM and install the update manually and give it a test or you can download it from the updates-testing repo. http://koji.fedoraproject.org/koji/buildinfo?buildID=679465

Since there is no update offered at this moment, I downloaded selinux-policy-3.13.1-128.12.fc22.noarch.rpm and updated from the RPM. Immediately got in trouble at the next boot: Failed to load SELinux policy, freezing. Maybe I was doing something wrong, but at this time it is a headache: after downgrading back to selinux-policy-3.13.1-128.10.fc22.noarch, only setting selinux=0 in the kernel allows to boot without problems.

That patch is for F22 (the fc22 in the rpm name denotes that, make sure that number matches the release you are using). Here is the policy for F23 http://koji.fedoraproject.org/koji/buildinfo?buildID=679463

Remove the f22 rpm and install this one

I am using F22 (not F23) as you can see from my comment above and below:

LSB Version:	:core-4.1-amd64:core-4.1-noarch
Distributor ID:	Fedora
Description:	Fedora release 22 (Twenty Two)
Release:	22
Codename:	TwentyTwo

Ah, sorry about that. I misread your first statement up there concerning the F23 update for F22. If you get a chance click on my username and send me an email, I will reach out and find some help with this.

@Andrew: If you just manually downloaded the rpm from koji, there might be other packages from that build that you have installed and would likely be expected to install alongside the selinux-policy one. I know on my system I also had selinux-policy-targeted, so I updated both of them at the same time. No idea if that could be related to your issue or not.

Thanks Gerard and Devon! 

After downloading and changing all 3 components that were installed on my system (not just one), I am all set now.

selinux-policy-devel-3.13.1-128.12.fc22.noarch
selinux-policy-targeted-3.13.1-128.12.fc22.noarch
selinux-policy-3.13.1-128.12.fc22.noarch

Thanks, selinux-policy-3.13.1-128.12.fc22 fixes it for me too

selinux-policy-3.13.1-128.12.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.