<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>tl;dr Pulp3 will have an SELinux policy at GA, and Katello will use it. In the future SELinux failures will require a functional test to demonstrate the failure before the SELinux error can be fixed.<br></div><div><br></div><div><br></div><div>For Pulp3's use in Katello, SELinux is a requirement, so we need to provide SELinux policies (for the 4 processes of Pulp) with the Dec 3rd planned GA date. I want to share a plan to do that, and ask for feedback and concerns.</div><div><br></div><div># Initial Policy Creation</div><div>I've reached out to the Red Hat SELinux team, and they have agreed to produce the initial policies for Pulp3 on Fedora 30 by end of October. They've provided a Fedora 30 box and we are to install Pulp3 on it with the GA plugins pulp_rpm, pulp_docker, and pulp_file. Additionally this install must be capable of running the functional tests which the SELinux team will run over-and-over as they develop the policy.</div><div><br></div><div>They will deliver the policy here where it will be stored long term for all OS's: <a href="https://github.com/pulp/pulp-selinux">https://github.com/pulp/pulp-selinux</a></div><div><br></div><div># What about CentOS 7 and CentOS 8?</div><div>After the Fedora 30 policy is created, a CentOS 7 policy will also be created and stored in the same repo. A CentOS 8 policy won't be created until Katello is prepared to ship RPMs on CentOS 8.<br></div><div><br></div><div># Delivery to Katello</div><div>The SELinux policy will be built into the Katello RPM packaging by the Platform and Delivery team at Red Hat, led by @ehelms. That is the same team building the Katello RPMs. These will only ship the CentOS 7 policy.<br></div><div><br></div><div># Maintenance over time</div><div>The Pulp team will maintain the SELinux policy, with support from both the Red Hat SELinux team and the community.<br></div><div><br></div><div></div><div># SELinux Failures will Require a Functional Test<br></div><div>As SELinux failures are discovered over time, the policy will need to be adjusted. To ensure the SELinux is straightforward I'm proposing a functional test must be present to demonstrate the failure. This will both increase functional test coverage, and allow the SELinux update to be efficient.</div><div><br></div><div>Please send feedback and concerns.</div><div><br></div><div>Thanks,</div><div>Brian<br></div><div><br></div></div></div></div>