Description of problem: On Fedora 24 (and 23) starting osad with systemctl fails because of selinux violations. I am currently unable to test this on Fedora 25, but I suspect the issue occurs there as well. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.13.1-191.24.fc24.noarch How reproducible: always Steps to Reproduce: 1. Install osad after registering with spacewalk server 2. do `systemctl start osad` 3. See it fail to start Actual results: Fails to start Expected results: osad starts Additional info: Fedora 24 audit log of failure... type=AVC msg=audit(1487685922.052:598): avc: denied { execmem } for pid=14137 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(1487685922.052:599): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:osad_t:s0 pid=14137 comm="osad" exe="/usr/bin/python3.5" sig=11 Fedora 23 audit log of failure... type=AVC msg=audit(1487685922.052:598): avc: denied { execmem } for pid=14137 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(1487685922.052:599): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:osad_t:s0 pid=14137 comm="osad" exe="/usr/bin/python3.5" sig=11 [eherget@eherget osad]$ cat audit-f23.log type=AVC msg=audit(1487693055.388:656): avc: denied { write } for pid=17548 comm="osad" name="osad" dev="dm-0" ino=16804629 scontext=system_u:system_r:osad_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1487693055.391:657): avc: denied { write } for pid=17548 comm="osad" name="osad" dev="dm-0" ino=16804629 scontext=system_u:system_r:osad_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1487693055.455:658): avc: denied { write } for pid=17548 comm="osad" name="osad" dev="dm-0" ino=16804629 scontext=system_u:system_r:osad_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1487693055.463:659): avc: denied { write } for pid=17548 comm="osad" name="osad" dev="dm-0" ino=16804629 scontext=system_u:system_r:osad_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1487693055.468:660): avc: denied { write } for pid=17548 comm="osad" name="osad" dev="dm-0" ino=16804629 scontext=system_u:system_r:osad_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1487693055.473:661): avc: denied { write } for pid=17548 comm="osad" name="osad" dev="dm-0" ino=16804629 scontext=system_u:system_r:osad_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1487693055.484:662): avc: denied { execmem } for pid=17548 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(1487693055.484:663): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:osad_t:s0 pid=17548 comm="osad" exe="/usr/bin/python3.4" sig=11 type=SERVICE_START msg=audit(1487693055.561:664): 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'
First part of f23 audit.log listing is dupe of f24 audit.log snippet... ignore first few lines and start from cat command.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. 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 '24'. 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 24 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.
This continues to be an issue on ALL fedora versions.
Where is OSAD writing under /usr? Most likely should not be doing writing there. execmem is usually frowned upon, Is OSAD a java application?
Created attachment 1308402 [details] audit.log with only osad startup AVC denials in permissive mode
Created attachment 1308403 [details] human readable output from sealert -a on the audit-save.log file
It looks like its trying to write to /usr/share/rhn/osad .. and within that directory, the __pycache__ directory. I've attached the audit.log of AVC denials when starting osad, done in permissive mode (audit-save.log). I've also attached the human readable output that comes from running sealert -a on the above audit.log output (audit-save.txt).
Can those files be precreated?
I don't know enough about how pycache works to answer that. I'll check with the team and see if that's an option.
/usr should be considered a readonly partition, And I believe python can be shipped with precompiled binaries.
If you look at locate pycache | xargs rpm -qf You will see lots of pycache files that are shipped as part of the rpm payload. The execmem, policy should probably be added.
I've looked at this with someone else and we notice that we ship the .pyo and .pyc (precompiled byte code) in the rpm, but it's in the osad dir, not osad/__pycache__. I compared this with set of files and directories laid down by the rhn-client-tools rpm. It too ships .pyo and .pyc files that go in /usr/share/rhn/up2date_client directory. This package, too, appears to create a __pycache__ directory and fill it with .pyo and .pyc files. The difference I notice is the label on this __pycache__ directory and the files it contains... The osad/__pycache__ is lableled system_u:object_r:usr_t:s0, just like everything else in the osad directory. The up2date_client/__pycache__ label is different from all the other content in the up2date_client directory... its label is unconfined_u:object_r:usr_t:s0 The content of the __pycache__ directory has the same label as the __pycache__ directory. I'm making an assumption that the unconfined_u:object_r:usr_t:s0 label on the up2date_client/__pycache__ directory results in no AVC denials when code is run that causes the __pycache__ content to be written. If that's the case, where is the label on the __pycache__ directory coming from?
No the content should be shipped in the __pycache__ directory. The unconfined_u means that an admin ran a command that wrote the content to that directory. The system_u means it was either installed or created by a script running by the system. An unconfined user is allowed to create content anywhere, but a confined domain like osad is not allowed to create content in /usr. If I allowed a confined domain to write this content, it would basically be allowing an application to rewrite itself. From a security point of view this is bad. Think about a hacked application that could rewrite itself, therefore leaving the hack for the next boot.
I've come across additional BZ reporting similar problem with firewalld being denied write access to __pycache__. Three BZs: https://bugzilla.redhat.com/show_bug.cgi?id=1467091 https://bugzilla.redhat.com/show_bug.cgi?id=1470969 https://bugzilla.redhat.com/show_bug.cgi?id=1418587 The first 2 are marked duplicates of the third. The third says it is COMPLETE CURRENTRELEASE on 2017-06-27, but I see nothing to indicate how this was fixed. Can we chase down how that BZ got resolved to see what we need to do here?
Not sure on any of them, but the solution is to package the content correct in your rpm. Look at rpmlint. rpm -ql rpmlint | grep pycache /usr/share/rpmlint/__pycache__ /usr/share/rpmlint/__pycache__/AbstractCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/AppDataCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/BinariesCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/Config.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/ConfigCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/DistributionCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/DocFilesCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/FHSCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/FilesCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/Filter.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/I18NCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/InitScriptCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/LSBCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/MenuCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/MenuXDGCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/NamingPolicyCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/PamCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/Pkg.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/PostCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/RpmFileCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/SCLCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/SignatureCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/SourceCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/SpecCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/TagsCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/ZipCheck.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/__isocodes__.cpython-36.opt-1.pyc /usr/share/rpmlint/__pycache__/__version__.cpython-36.opt-1.pyc
The firewalld BZs say this issue was introduced when they upgraded to selinux-policy-3.13.1-225.6.fc25.noarch also mentioned are selinux-policy-3.13.1-225.10.fc25 selinux-policy-3.13.1-225.11.fc25 selinux-policy-3.13.1-225.18.fc25.noarch Given the timing of the initial firewalld report (2017-02-02) and this BZ (2017-02-21) it appears to be this policy change that started the issue. I'd like to understand how the selinux-policy change resulted in this issue and how the firewalld issue was ultimately resolved. If python3 is writing stuff to __pycache__ directories, and python code lives in /usr/python../site-packages/..., I would imagine there will be lots of reports on the selinux denials that have occurred since this policy change. Googling, I find many such reports, all starting in early February - abrt, gdb, hpfax, python3, etc.
Ok... I think I see the various aspects of this issue. On our side - osad - we are not packaging pyc and pyo files in __pycache__ directory as appears to be the place python3 expects them. We are shipping them in the same dir with the .py files as done on python2 In addition, there was apparently an issue in some version of python3 that had issues with legacy pyc and/or pyo files after upgrading to python-3.5.3 that resulted in these same denials. 3.5.3-3 appears to fix this issue I will get with our team to work out packaging the pyo and pyc files in the correct location (__pycache__ directory).
That leaves the execmem policy to be added - mentioned in comment # 11 Is that something you would add to selinux-policy package? Or do we do that during the rpm install?
It should be fixed in the selinux-policy package. Lukas can you make the change.
Done. Moving to POST
selinux-policy-3.13.1-260.14.fc26 has been pushed to the Fedora 26 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-2017-d312739a4e
selinux-policy-3.13.1-260.14.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.