Created attachment 806189 [details] Patch to be applied to fedpkg git for selinux and httpd improvements. Description of problem: Out of the box, radicale runs as an unconfined domain. Additionally, the shipped httpd configuration has many subtle issues that prevent easily changing between httpd and radicale's daemon. Finally, httpd's selinux policy may conflict with radicale. This patch (can be applied to fedpkg) adds selinux policy to config radicale to a domain (radicale_t), as well as adding etc types, log type and file types for collections or the sqlite db. Additionally, it adds a boolean allowing httpd rw access to radicale content. The httpd configuration now omits the wsgi lines, as these come with mod wsgi. The wsgi process is run as the radicale user, to prevent changing DAC permissions on the fs. The directory directive was changed to a location, to better suit the WSGI process. What this patch doesn't provide: SElinux policy to allow the radicale daemon to connect to SQL or LDAP. When running in WSGI mode, the radicale server is running as httpd_t, so the existing booleans for SQL and LDAP here cover that use case.
IMHO the selinux enhancements should be added to the default selinux policy. Or is there a good reason not to do this? @William: Can you please open a separate patch for the httpd improvements? Can you please explain these changes to the httpd config file, you do not mention them in the bug description: -# Require local +# # Require local # </IfModule> # <IfModule !mod_authz_core.c> # # Apache 2.2 @@ -27,6 +27,7 @@ # </IfModule> # # ## You may want to use apache's authentication +# AuthBasicProvider file
Normally policy when first developed, should go in a package specific module (Or the package itself). Once it's stabilised and improved, then it's generally put into the reference policy. Given I wrote it less than 24 hours ago, i think it best to keep it separate for now in case it needs improvement, over haul etc. I was using this module with apache24 on f19. The changes you note, Require local, can probably be uncommented if you want (Rather, ignored). It somewhat doesn't make sense to double block a user from accessing the service given out of the box, iptables blocks 80,443, and that the configuration is commented out anyway. It's another "step" for a user to need to reconfigure. (This is a minor issue) AuthBasicProvider file can likely be removed also: I was used to it needing to be specified, and think it good practice to be specific. I just double checked and found that it is the default anyway.
Created attachment 806479 [details] Httpd patch
Created attachment 806480 [details] Selinux patch
I have merged the httpd config changes, adding a umask value to the process. I have also removed the whole block of network access rules, as it makes little sense. About the SELinux rules, they look ok for me, but I'll wait to hear what the SELinux experts have to say about them.
Policy looks good to us.
radicale-0.8-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/radicale-0.8-4.fc20
Package radicale-0.8-4.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing radicale-0.8-4.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18460/radicale-0.8-4.fc20 then log in and leave karma (feedback).
radicale-0.8-5.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/radicale-0.8-5.fc20
radicale-0.8-5.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
So radicale's SELinux policy still seems to be shipping in a separate package; should it be merged into policy-targeted by now?
(In reply to Adam Williamson from comment #11) > So radicale's SELinux policy still seems to be shipping in a separate > package; should it be merged into policy-targeted by now? Is there a problem with that? I don't have a problem to ship in Fedora but there needs to be a request for it.
eh, I wouldn't say it's really a problem, it just seemed like we kinda had a policy of rolling everything up into the central package. It did confuse me for a bit because radicale doesn't require radicale-selinux, so until I realized I needed to install the subpackage I couldn't get it to work with selinux.
(In reply to Miroslav Grepl from comment #12) > Is there a problem with that? I don't have a problem to ship in Fedora but > there needs to be a request for it. How should I request it? opening a bug to policy-targeted?
I would say this is a bug in radicale, it should require the radicale selinux policy. We want to encourage apps to ship their own policy especially going forward with the improvements in the SELinux tool chain. I would like to get policies reviewed and they could be stored in the upstream git, but we really want to start to shrink the size of policy by not installing it if it is not needed.
Ok if there is radical-selinux.rpm with policy, then it should be required by radicale. My point is we can store policy files in fedora-selinux github and these sources can be used by a packages which shipped own policy. We really need to be sure these policies are upstreamable. Also there are some policy language limitations if they are outside of the distro policy (see docker.te and mainly *_stub() calling). The biggest point is we can use module priorities https://mgrepl.wordpress.com/2015/07/31/cil-part2-module-priorities/ and start to think about profiling. Something what we have for selinux-policy-minimum.
(In reply to Miroslav Grepl from comment #16) > Ok if there is radical-selinux.rpm with policy, then it should be required > by radicale. Hi, I've submitted this update requiring radicale-selinux: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15287 I think the policy is enough tested to be pushed to everyone.