Description of problem: /usr/lib/systemd/systemd-socket-proxyd has incorrect type. It does not allow it to connect to unprivileged port. Version-Release number of selected component (if applicable): selinux-policy-3.14.5-41.fc32.noarch selinux-policy-targeted-3.14.5-41.fc32.noarch systemd-245.6-2.fc32.x86_64 How reproducible: reliable Steps to Reproduce: 1. systemctl start minecraft-proxy.socket 2. telnet 127.0.0.2 25565 3. Actual results: type=AVC msg=audit(14.8.2020 15:31:46.043:10505) : avc: denied { name_connect } for pid=5624 comm=systemd-socket- dest=25565 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0 Expected results: No error. Additional info: #minecraft-proxy.service # /etc/systemd/system/minecraft-proxy.service [Unit] Description=Minecraft offline/localhost workaround Requires=network.target After=network.target [Service] ExecStart=/usr/lib/systemd/systemd-socket-proxyd 127.0.0.1:25565 [Install] WantedBy=multi-user.target # /etc/systemd/system/minecraft-proxy.socket [Socket] ListenStream=127.0.0.2:25565 [Install] WantedBy=sockets.target
It is possible to enable it by setsebool -P nis_enable 1. But it seems to me this boolean is for very different use cases.
Turning on the boolean really is for a different use case. We may need to have a new policy for systemd-socket-proxyd.
Discussed with systemd people, decreasing priority for writing new SELinux policy for systemd-socket-proxyd. This tool is not widely used.
How can one use it, when it does not work? Can you give correct workaround at least?
Ditto to Comment 4. There appears to be a workaround posted here: https://dmitry.khlebnikov.net/2017/01/13/nginx-a-backend-with-a-dynamic-ip-eg-aws-elb/
Petre, Take a look at the link posted by Gregory, it's very well explained there. Gregory, Thank you for the link.
Closing thiz BZ. For the workaround and further information, refer to the link in c#5.
Please, either remove the tool completely, because it just does not work. Or make it working. Workaround is about temporary SELinux policy. While I would accept the solution on CentOS, where new changes should not propagate, I think there is no better place to fix this eventually than Fedora. What is purpose of that tool, if not connecting to ports? Can you just remove it from the package, if its use is so unimportant? If it is not fixed in Fedora, would it be broken forever? Do you want propagate "turn off SELinux" 'solution' for some reason?
As I understand it, comment #5 expects it fixed someday and offers only temporary fix until that is done. If it should not be done in Fedora, can I report the issue upstream? I am not sure, does it belong to different place?
Because selinux-policy people do not want to fix this tool's default policy, can it be just removed from the package? Why is the tool unable to serve its only purpose? Can it be fixed by systemd package somehow?
(In reply to Petr Menšík from comment #10) > Because selinux-policy people do not want to fix this tool's default policy, > can it be just removed from the package? Why is the tool unable to serve its > only purpose? Can it be fixed by systemd package somehow? There might be plenty of users running with SELinux disabled.
Do we want to encourage people to disable SELinux, when we do not offer an alternative?
(In reply to Petr Menšík from comment #8) > I think there is no better place to fix this eventually than Fedora. I think the better place is the reference policy (https://github.com/SELinuxProject/refpolicy) all distributions are building theirs upon. I am going to submit my module there and it will eventually propagate to the distributions.
Oh, and the link in #5 was to my blog, by the way :)
Submitted the policy to the refpolicy repository: https://github.com/SELinuxProject/refpolicy/pull/315
Awesome! Thanks Dmitry!
(In reply to (GalaxyMaster) from comment #15) > Submitted the policy to the refpolicy repository: > https://github.com/SELinuxProject/refpolicy/pull/315 Thanks! I did not know there is a SELinux upstream. I would expect selinux people creating such upstream MR before closing the bug, or at least make issue there.
I hit a road block and need some help. After all the cosmetic changes the maintainer is happy with the PR, but refuses to recognise my identity to actually merge the change. If you are interested to push the work upstream, please fork my PR and submit it as yourself, since I am not dealing with people who bully others to accept their point of view unconditionally.
I'm sorry to hear that Dmitry. :( Unfortunately, I don't have any more say about how SELinux operates than you. If they've said no then I suspect that's the end of it. On the plus side, your blog might get a few more hits over the coming years. Thanks for your work and please keep it published.
Sorry, I replied before I looked at the pull request. I see that the issue wasn't with your code but some nonsense about your email address. It looks like they have retracted their erroneous position and are now willing to accept the pull request.
The pull request has been successfully merged upstream, so the next release of the policy should contain the necessary changes to support `systemd-socket-proxyd` out of the box.
Thank you for your help. Glad they could merge it eventually.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. 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 '32'. 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 32 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.
Closing as NEXTRELEASE per comment #21.