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
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