SELinux policy within package managers, why policy is special*
SELinux policy is currently installed from a single or multiple package(s) as an application which breaks the linkage between policy and the software they are constraining. We will talk about a way to treat policy specially without adding downfalls such as a large increase in packages.
SELinux policy is currently treated as if it were another application. In most distributions, it is a single package that exists on its own as if it did not relate to the software to which it applies. Consequently, there is no way to ensure that policy matches installed applications. Further, any maintenance of policy must be performed manually via post install scripts, which is both tedious and error-prone. It is also very difficult to ensure that policy and the applications it confines are installed in the proper order, meaning that applications can be labeled improperly for a window of time.
We propose solving this for package managers to treat policy as metadata rather than an application. This metadata can exist in the package of the application it applies to, or in system packages for more broad policy. This solution alleviates the pain of manually maintaining policy in scripts by giving the package manager enough information to manage policy automatically. By treating policy as metadata, it can be installed at the appropriate time in order to avoid ordering issues. As a side benefit, all policy module installations can be combined during a package manager transaction, reducing the performance hit taken when splitting policy into multiple packages.
SELinux, package managers, RPM
Joshua Brindle is a senior engineer at Tresys Technology where he does research and development with Security Enhanced Linux (SELinux). He has worked at Tresys for 5 years and has been working with SELinux for 8 years.