SELinux is famous for its thorough access control over the whole Linux box, but also notorious for the steep learning curve. The bundled open-source Reference Policy provides detailed security rules for a common Linux system, using the SELinux mechanism. However, system administrators usually have to tinker for the particular needs, on top of the Policy. Usually, it is done by audit2allow disregarding all denies, or fiddling the subject/object types using chcon to bypass the Policy denial. Such trial-and-error activities usually open an inadvertent vulnerability because it lacks security review. Even with the review in place, most people do not have enough knowledge to judge the effects of the alteration. Hence, SELinux is always a black-magic around IT personnels.

In the meantime, thanks to the rise of cybersecurity attacks, people today pay much more attention to the light-weight solutions like whitelisting. In short, it is allowing or denying the program (or any subject) at the time of invocation. Its simplicity brings the popularity, to an extent that some people believe whitelisting is everything to security. To support the thinking, we made an experiment throwing away the Reference Policy and craft a so-called WhiteList Policy using the SELinux framework from scratch. It is intended to show 1) the loaded policy determines easy-to-use or not, not SELinux mechanism; 2) solution to security issues is a trade-off between many aspects, convenience and completeness especially; 3) there is always a gap between the theory and the practice on all security solutions , even the one simple as whitelist.