Cover SELinux configuration

[mbukatov]

Based on SELinux section in https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.5.2-(install-guide), update tendrl-ansible (most likely add tendrl-selinux role).

Specification

• issue: Enable SELinux for tendrl specifications#241
• pull request: Run tendrl in SELinux enabled specifications#244

Actual Implementation

SELinux policies are maintained in selinux directories of these 2 repositories:

• tendrl-api
• tendrl-gluster-integration

So that there are the following SELinux packages:

In tendrl-api spec file:

carbon-selinux-1.5.2-20170927T205654.a9e16c0.noarch.rpm
tendrl-grafana-selinux-1.5.2-20170927T205654.a9e16c0.noarch.rpm
tendrl-server-selinux-1.5.2-20170927T205654.a9e16c0.noarch.rpm

In tendrl-gluster-integration spec file:

tendrl-collectd-selinux-1.5.2-20171002T062306.f428920.noarch.rpm
tendrl-node-selinux-1.5.2-20171002T062306.f428920.noarch.rpm

Questions to figure out

• Why we have tendrl-collectd-selinux rpm and carbon-selinux rpm? Having tendrl- prefix is a valid approach, as long as tendrl-collectd policy overrides collectd policy from selinux-policy package. Having no prefix could work as long the policy is not covered in selinux-policy package.

• Is it ok to maintain SELinux policies in 2 unrelated repositories?
  No, this is not a good idea. While it would be ok to attach selinux policy to one of already established repositories (as written in the specification), spreading it into 2 repositories and covering 3rd party components is not, as it unnecessary increases work required for maintenance.

• Is it ok for specfile for gluster-integration or api to contain selinux policies of 3rd party packages? No, it's not ok.

• There is a conflict between node and server package (see below). Is this ok?

  # rpm -ql -p tendrl-node-selinux-1.5.2-20171002T062306.f428920.noarch.rpm 
  /usr/share/selinux/packages/tendrl.pp.bz2
  # rpm -ql -p tendrl-server-selinux-1.5.2-20170927T205654.a9e16c0.noarch.rpm 
  /usr/share/selinux/packages/tendrl.pp.bz2
  

  No, this is not ok.

• What a default mode of the tendrl domains should be? It should be permissive.

Related Issues and Details

• tendrl services should run in selinux permissive domain node-agent#604
• Primary Selinux policy for tendrl api#261 (pull request with primary policy, already merged)

Blocker Issues

While I'm able to work on SELinux setup outright, I'm not going to merge the changes without these issues being addressed:

• [selinux] postinstall and postuninstall scripts should not contain restorecon -Rv / gluster-integration#424
• [selinux] postinstall and postuninstall scripts should not contain restorecon -Rv / api#291

Status update: I'm going to fix these issues during work on moving selinux code into single repository tendrl-selinux.

Upstream Guidelines

https://fedoraproject.org/wiki/SELinux/IndependentPolicy

[mbukatov]

I need to verify current setup with someone from SELinux team first to prevent automating flawed setup. Moving to milestone for 1.5.3.

[mbukatov]

I'm working on moving all selinux bits into single repository, work in progress repository is available here: https://github.com/mbukatov/tendrl-selinux , when finalized and after agreement with tendrl dev team, the repo will be moved into Tendrl github group and selinux code from api and gluster integration repositories will be removed.

[mbukatov]

Repository https://github.com/mbukatov/tendrl-selinux is ready to be transfered into Tendrl organization. Related pull requests:

• remove selinux code api#321
• remove selinux code gluster-integration#443

[mbukatov]

Status update:

• repository with selinux policies has been transferred into https://github.com/Tendrl/tendrl-selinux
• the idea behind SELinux support for Tendr is that we will keep SELinux in enforcing mode, but will have our independent policies in permissive, so that we can catch the problems.

[mbukatov]

Implemented by #55