Hide Forgot
Description of problem: Hi, we need add new selinux rule for osad to Fedora 23. We received following message in audit.log. type=AVC msg=audit(1462198745.064:6466): avc: denied { write } for pid=20175 comm="osad" name="urandom" dev="devtmpfs" ino=6936 scontext=system_u:system_r:osad_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file permissive=0 Version-Release number of selected component (if applicable): selinux-policy-targeted-3.13.1-158.14.fc23.noarch How reproducible: always Steps to Reproduce: 1. install osad in enforcing mode 2. systemctl restart osad 3. look at osad and audit logs Actual results: tail /var/log/osad File "/usr/share/rhn/osad/osad.py", line 81, in setup_config self._setup_config(config, force) File "/usr/share/rhn/osad/osad.py", line 121, in _setup_config auth_info = self.read_auth_info(force) File "/usr/share/rhn/osad/osad.py", line 391, in read_auth_info username = 'osad-%s' % jabber_lib.generate_random_string(10) File "/usr/share/rhn/osad/jabber_lib.py", line 1381, in generate_random_string devrandom = open('/dev/urandom', "rb+") PermissionError: [Errno 13] Permission denied: '/dev/urandom'
Pavel, Why is write permission needed, here?
Hi, thanks, it was bug in osad. But now I receive following avc message: >> tail /var/log/audit.log type=AVC msg=audit(1462358596.496:7789): avc: denied { execmem } for pid=9041 comm="osad" scontext=system_u:system_r:osad_t:s0 tcontext=system_u:system_r:osad_t:s0 tclass=process permissive=0 type=ANOM_ABEND msg=audit(1462358596.509:7790): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:osad_t:s0 pid=9041 comm="osad" exe="/usr/bin/python3.4" sig=11 type=SERVICE_START msg=audit(1462358596.573:7791): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=osad comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' >> audit2allow -a #============= osad_t ============== allow osad_t self:process execmem; Problem is only when I try to run service by systemctl. Some idea what can be wrong?
Osad is trying to make executable an anonymous mapping or private mapping that is writable. This can be dangerous. Any idea why?
No, I don't know. It is strange. My investigation: I disable selinux and I run service: >> systemctl start osad Active: active (running) since Wed 2016-05-04 10:01:35 EDT; 2s ago Process: 9652 ExecStart=/usr/sbin/osad --pid-file /var/run/osad.pid (code=exited, status=0/SUCCESS) Main PID: 9654 (osad) CGroup: /system.slice/osad.service `-9654 /usr/bin/python3 -s /usr/sbin/osad --pid-file /var/run/osad.pid May 04 10:01:34 test04-64.sysmgmt.lab.eng.rdu2.redhat.com systemd[1]: Starting OSAD daemon... May 04 10:01:35 test04-64.sysmgmt.lab.eng.rdu2.redhat.com systemd[1]: osad.service: PID file /var/run/osad.pid not readable (yet?) after start: No such file or directory >> ps aux | grep osad root 9619 0.7 0.8 215556 17680 ? S 09:59 0:00 /usr/bin/python3 -s /usr/sbin/osad --pid-file /var/run/osad.pid And after that I enable selinux. When I run service manually it works correct. >> /usr/bin/python3 -s /usr/sbin/osad --pid-file /var/run/osad.pid But if I start service by systemctl then I receive avc message and service ends. -- The result is failed. May 04 10:09:22 test04-64.sysmgmt.lab.eng.rdu2.redhat.com systemd[1]: osad.service: Unit entered failed state. May 04 10:09:22 test04-64.sysmgmt.lab.eng.rdu2.redhat.com systemd[1]: osad.service: Failed with result 'core-dump'. This service uses python3 and I don't know how can I find problematic code.
I think these are similar bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1249685 https://bugzilla.redhat.com/show_bug.cgi?id=1277224 bug in libffi I soppose https://github.com/pyca/cryptography/issues/2477 was closed on Nov 13, 2015, our version is libffi-3.1-8.fc23.x86_64 was builded on Wed 17 Jun 2015 01:07:43 PM EDT
If you run it by hand it is running as unconfined_t, if you run it via the init script it is running as a confined domain osad_t. Python has some funky stuff with handling glibc bindings that can cause execmem, as I recall. Did the service run correctly even though it generated this avc in enforcing mode?
In enforcing mode it cannot be executed, but in permissive w/o problems.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. 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 '23'. 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 23 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.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.