Hi guys, Another SELinux question mail. While developing SELinux policies for system services, I often hit the problem that we don't have a "security model" in place that defines (or documents) how we want to tackle policy development for services.
For desktop applications, we somewhat have one [1] which tells us that we want application isolation, and through the XDG support and the userdom_user_content_access_template() we allow users to tune how they want applications to access user resources. It isn't written down in a proper security model yet (which I know have as a TODO) but seems to work pretty well, and is one of the features that Gentoo Hardened offers that isn't available in other distributions. [1] https://wiki.gentoo.org/wiki/Project:SELinux/Development_policy For servers though, we don't have anything that resembles a security model yet. Sure, we have the implementations that the reference policy provides, but those are quite generic and often also depending on the principles that the policy authors of said policies had in mind. Recently, with the development of the tmpfiles policy and salt(stack) policy, we are hitting the problem that no security model is defined yet. That makes policy development challenging, not for the individual policies, but to put them in a bigger picture. So I'm thinking about a certain security model that *I* would like to see, and am looking for some feedback on, as I'd like to implement that then for Gentoo Hardened. The idea is that four specific, privilege sets are supported on system domains: system monitor The system monitor privilege set allows for a system domain to read various file types (although I'm not sure if I want it to include security sensitive ones or not), system state (like sysctl values), process states, etc. It is a read-only set of privileges. software admnistrator The software administrator privilege set allows for a system domain to manage various file types (but not, or only in a very controlled manner, security sensitive files). system state administrator The system state administrator privilege set allows for system state handling, including sysctl values, network configuration settings, etc. security administrator The security administrator privilege set allows for security-sensitive types to be managed, including SELinux policy. Such privilege sets would be used for system domains to differentiate what they can do, and would benefit things like configuration management tooling. For instance, it could result in the following SELinux booleans for such tooling: *_monitor_system Read and monitor system files and system state *_admin_software Manage non-security-sensitive files and resources *_admin_system_state Manage system state and networking *_admin_security Manage security-sensitive files and SELinux policy When developing policies, the four privilege sets would be kept in mind and, of course as long as it makes sense, segregated and tunable. Without such security model in mind, we are most likely going to have SELinux policies that are very broad (without being tunable). And too broad policies means that the effectiveness of SELinux is being downplayed. Of course, it goes further than just the "privilege sets" mentioned above. We would also need to properly handle types so that "security sensitive" is more defined. Right now, the SELinux policy supports security-sensitive resources, but limits it very drastically: only shadow_t, audit_spool_t, auditd_etc_t, auditd_log_t and krb5_keytab_t are marked as security-sensitive on my workstation. We should probably extend that set drastically, including all types that have an impact on the secure state of a system. Imo, this includes types such as initrc_exec_t, boot_t, selinux_*_t, etc. But marking those types as security-sensitive types might have implications we don't currently see yet. What would the implications be of this security model for existing SELinux users on Gentoo Hardened? Well, this would not be "big" to start with. Domains that are intended to be package management domains (like portage_t) will remain so - it makes no sense to make portage_t a domain that "optionally" is a software management domain. The implications are more in light of policy development (and vision behind it). The tmpfiles policy for instance would by default be able to handle the "standard" types (as is already the case), but would optionally be able to handle non-security-sensitive files through a commonly named boolean (_admin_software might not be the best name, but don't focus on naming right now). So just like we do with desktop applications (where confinement on the user resources is handled) a similar approach for system services would be used (of course where it makes sense). Your feedback is definitely appreciated. Wkr, Sven Vermeulen
