How I think distribution maintainers can enhance quality assurance

Here is a list with things distribution maintainers can do to enhance quality assurance

1. Do proof reading.

This enhancement applies to some distributions more than others. Lets define those "active" distribution and "passive" distributions.

An active distribution is one that is constantly changing. Whereas a passive distribution is mostly "stale", and changes less frequent.

A property of active distributions is their activity. Fast development where Security policy must constantly be adapted to support these fast developments.

Maintaining policy for such scenarios is just hard work often. Things must be "fixed" quick and often. This is a recipe for human error.

Because often in the rush one tends to make assumptions, plain types and syntax errors, or other relatively simple mistakes.

Proof reading commits, and a fresh pair of eyes can save time here. By just spending a little day each day reviewing new commits such errors can be identified and fixed quickly.

Some of this proof reading requires humans for example identifying mistakes due to assumptions. Other proof reading can be automated, for example typos and syntax errors.

These human mistakes are often relatively harmless but sometimes they are harmful. The point i am trying to make is that this can be easily prevented.

For the record, i am not suggesting that this proof reading is for identifying complex issues. Because that is a but more complicated and probably takes a little more time

No instead i am suggesting that this method can filter out obvious errors. I can tell you from experience that this pay's off. Besides how hard is it to spend a little time regularly running a couple scripts on new commits to spot typos, syntax errors, and to spend five minutes a day reviewing yesterdays commits.

2. Test you policy for all common scenarios.

Policy can be built with various options. Distributions often do not use all these options. Problems can arise when you do not test building the policy with all options. This might be irrelevant in the short term because i head distribution maintainers think, if it works for us then why bother?

There are two reasons for that:

A. Your priorities might not align with the priorities of upstream, and for your own sake it is better to work with upstream. The more you divert the harder it gets to maintain your project. Merging new upstream releases becomes harder and take more time. By just making sure things work for all scenarios you increase chances of your changes being applied upstream. If you policy only works with a subset of options than upstream has little choice than to refuse the patch. To waste your time, upstreams time. its inefficient.


B. Besides. We know what SELinux is right. What defines SELinux. Its the flexibility and configurability. That's why i use SELinux as opposed to any of the other LSM-Based MAC systems. So as a distro maintainer i would actually advertise these properties. One obvious and easy way to do that is to make sure you project builds and installs in all common scenarios.

Sure there are limits to what you can support. Lets just use the same limits are upstream since we depend on eachother.

So, every once in a while. build your policy with different sets op options, to make sure that it builds. Also You might want to every onces in a while install it with various options that way you can identify bugs in the user space component.

Because this is not only an issue with policy, its also an issue with user space. User space must support all common policy and all its options.

3. Make sure that what you target at least works in common configurations.

If you target a daemon then it might be good to write a simple test for some of the common configurations. I am not suggesting all-inclusive tests. Just some default test to make sure the most obvious functionality works. It obviously requires some investments, at least initially but it might just mean the difference between a good or a bad impression.

4. Test your security goals.

Good, the processes you target can function and you have a way to verify that. But what about security? thats what we do all this for. Simple changes to the policy can have huge effects. By defining your security goals, and crucial properties of your security identifiers, you make it possible to verify that they meet your requirements over time. Run simple tests. We have great tools for that.
This can be automated perfectly

5. Other processes and SELinux

In essence SELinux is transparent to the user space. However user space components can be made aware of SELinux or can even be expected to manage parts of SELinux. For example setting security contexts on files. These programs are often written by parties that might not understand SELinux principles and concepts as well as some of us do.

This can affect the SELinux experience as a whole so its in our interest that these processes make the right decisions. One common mistakes is processes hardcoding security identifiers. Generally harmless but it harms experience and it can easily be prevented by loading a bare (dummy) policy and then checking dmesg or whatever to see if some processes are trying to use identifiers that do not exist. There are more conceivable tests imaginable.

These are just some ways distribution maintained can enhance quality assurance. Many of these point apply to both the security policy component as well as the user space component