www-servers/hiawatha is relatively new in the tree and is a web server. Localy I've added the following file contexts to get hiawatha running in the httpd_t type context with access to the proper files and directories: /etc/hiawatha(/.*)? all files system_u:object_r:httpd_config_t /usr/bin/ssi-cgi regular file system_u:object_r:httpd_exec_t /usr/sbin/cgi-wrapper regular file system_u:object_r:httpd_exec_t /usr/sbin/hiawatha regular file system_u:object_r:httpd_exec_t /usr/sbin/wigwam regular file system_u:object_r:httpd_exec_t /var/lib/hiawatha(/.*)? all files system_u:object_r:httpd_var_lib_t /var/log/hiawatha(/.*)? all files system_u:object_r:httpd_log_t I am new to SELinux and filing bugs against it, so just a question: do I need to open a separate bug report against www-servers/hiawatha for the USE flag dependency?
A separate bug is always the easiest, but this bug is sufficient as well. I'll confirm the contexts and update the dependency as well.
I would also add in /etc/rc.d/init.d/hiawatha for httpd_initrc_exec_t. However, I failed to be able to get it to run without adding: allow httpd_t self:capability fowner; It complains about setting access rights on /var/lib/hiawatha (even though the rights are correct).
Can this have something to do that hiawatha is trying to change the owenership of newly created directory `uploads` /var/lib/hiawatha is owned by hiawatha:hiawatha and has mode 700 /var/lib/hiawatha/uploads is owned by root:root and has mode 777 The deamon is running as linux user hiawatha On my sysem it was able to do this, because I am still in permissive mode and this must have slipped my attention in the logs. `uploads` is not part of the package, but is created by the hiawatha deamon. I wonder if the ownership should really be root:root and not remain in hiawatha:hiawatha. Again, I am new to SELinux, but I can imagnine SELinux is blocking this action. Is this possibly a bug in hiawatha? Eg: the ownership is hard-coded, while the deamon should honor the user it is running under.
It's not per se about the uploads directory, but that it is repeatedly done (on every start of the process). I allowed it once, and then disabled it again and the application refused to restart again (even though the privileges would be ok and, after some quick checking, didn't show up as different). It doesn't necessarily constitute a bug in the application though. It's not "nice" in the sense that it is forcing a change even if the resource is already properly owned and set, but it doesn't hurt either (wouldn't be the first application that acts like that). SELinux basically checks the policy to see which system calls are performed by the application (by then running in the httpd_t) domain and see if those system calls are allowed. As the other web server daemons that are running inside httpd_t don't need this privilege, the policy doesn't contain it by default. What we can do is something similar to how we work things out for fcrond: the cron policy was updated with a tunable for the fcrond setup, enabling specific accesses if the administrator selected the cron_fcrond boolean. If not selected, then the additional privileges are not granted. We can do something similar for the web server domain, creating something like an httpd_hiawatha boolean which "enables" the additional privileges that the hiawatha web server would require. In the long(er) term though, we might want to check if the policy rules for the web server for hiawatha specifically are sufficiently similar to those of the httpd_t domain. It might be that hiawatha requires much less privileges than httpd_t - SELinux will happily allow hiawatha to run in a more privileged domain, even though that isn't as secure as it might be.
I've included the changes in our repository, so our live ebuilds already contain it. The change will also be in our future builds (so the next one is rev 4). The boolean that enables the fowner capability is called "hiawatha_httpd".
Great! I've also dropped a message at the developer if the fowner behaviour is really needed. He will fix it in his next release, so maybe in time the boolean can be removed again.
r4 is in the tree, ~arch
r5 is stable
