puppetboard has no explicit SELinux context for httpd

[t-valette]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.23.0
• Ruby: 2.0.0p648
• Distribution: Centos 7
• Module version: v8.0.0

How to reproduce (e.g Puppet code you use)

Run puppet with puppetboard and default parameters

What are you seeing

puppetboard is installed correctly, but has a bad context to be used with httpd:

$> ls -Z
drwxr-xr-x. puppetboard root        system_u:object_r:var_t:s0       puppetboard

What behaviour did you expect instead

puppetboard should be under the httpd_sys_content_t context:

$> ls -Z
drwxr-xr-x. puppetboard root        system_u:object_r:httpd_sys_content_t:s0 puppetboard

Any additional information you'd like to impart

A simple workaround is to manually run (which could be a security issue regarding some files)

$> semanage fcontext -a -t httpd_sys_content_t "/srv/puppetboard/puppetboard(/.*)?"
$> restorecon -R -v /srv/puppetboard/puppetboard

However, this step could be optional if we explicit the SELinux context

Could be linked to #228 ?

[bschonec]

Would a simple addition of:

selinux::fcontext {'puppetboard': seltype => 'httpd_sys_content_t', pathspec => '/srv/puppetboard(/.*)?, }

suffice if $::puppetboard::manage_selinux is true?

[jhunt-steds]

Would a simple addition of:

selinux::fcontext {'puppetboard': seltype => 'httpd_sys_content_t', pathspec => '/srv/puppetboard(/.*)?, }

suffice if $::puppetboard::manage_selinux is true?

That does make Puppetboard stop throwing 500 Internal Server Error and probably would be enough for most use cases. However, if you're using SSL to connect to PuppetDB on a different server it can't verify the cert, because SELinux doesn't permit Apache to read any of the certs it uses to verify the connection (/etc/puppetlabs/puppet/ssl/certs/ca.pem and the Puppet cert/key for the Puppetboard server e.g. /etc/puppetlabs/puppet/ssl/certs/puppetboard.example.com.pem and /etc/puppetlabs/puppet/ssl/private_keys/puppetboard.example.com), because that file a type of puppet_etc_t. If I copy them someplace that labels them with httpd_sys_content_t instead it does work, so this issue can be worked around, and maybe having Puppetboard on a different server is an edge use case. On the other hand, if you're looking for a one-stop "just works" solution it'd be necessary to either relabel the certs (probably bad) or allow Apache to read files labeled with puppet_etc_t (could have unintended consequences), or I guess make up some new type for the certs and allow both Puppet and Apache to read it. The last one might be out of reach because, I'm guessing, it'd require work from upstream.