| Message ID | 20180320210518.9982-1-aconole@redhat.com |
|---|---|
| Headers | show |
| Series | selinux: introduce a transition domain for loading kmods | expand |
On Tue, 20 Mar 2018 17:05:14 -0400 Aaron Conole <aconole@redhat.com> wrote: > On linux systems, the initial start of openvswitch attempts to load > the openvswitch.ko kernel module. This module allows openvswitch to > utilize the kernel datapath. > > Some of these linux systems, notably Fedora and RHEL, use selinux to > enforce additional restrictions on various processes by way of > allowing or disallowing access from a specific selinux domain to a > particular operation on an selinux type. On these systems, the > openvswitch initialization will be run from the 'openvswitch_t' > selinux domain. Attempts by a process in the 'openvswitch_t' selinux > domain to load a kernel module will be denied. > > One solution would be to simply allow 'openvswitch_t' to load a kernel > directly. This essentially means that 'openvswitch_t' would really be > 'unconfined_t' - since an attacker that can control the code can issue > a kernel load. > > The solution implemented here uses a labeled file in the openvswitch > scripts directory, which is writable only by root. That file will > force a domain transition to the 'openvswitch_load_module_t' domain. > The 'openvswitch_load_module_t' domain will then be granted > permissions to load a kernel module. > > Please vet the new permissions in 2/4 *carefully*. I've tried to keep > it as restricted as possible. If there are any useful selinux > interfaces that would simplify the permission grants needed for the > new domain, I'm happy to spin a v2. > > Aaron Conole (4): > ovs-kmod-ctl: introduce a kernel module load script > selinux: create a transition type for module loading > selinux: introduce domain transitioned kmod helper > rhel: selinux-policy to invoke proper label macros > > debian/openvswitch-switch.install | 1 + > debian/openvswitch-switch.manpages | 1 + > rhel/openvswitch-fedora.spec.in | 12 +- > rhel/openvswitch.spec.in | 2 + > selinux/.gitignore | 4 + > selinux/automake.mk | 3 +- > selinux/openvswitch-custom.fc.in | 1 + > selinux/openvswitch-custom.te.in | 79 ++++++++++++- > utilities/.gitignore | 1 + > utilities/automake.mk | 5 + > utilities/ovs-ctl.in | 32 +----- > utilities/ovs-kmod-ctl.8 | 103 +++++++++++++++++ > utilities/ovs-kmod-ctl.in | 228 > +++++++++++++++++++++++++++++++++++++ > utilities/ovs-lib.in | 12 +- 14 files changed, 439 > insertions(+), 45 deletions(-) create mode 100644 > selinux/openvswitch-custom.fc.in create mode 100644 > utilities/ovs-kmod-ctl.8 create mode 100644 utilities/ovs-kmod-ctl.in > Series Acked-By: Timothy Redaelli <tredaelli@redhat.com>
On 20 March 2018 at 14:05, Aaron Conole <aconole@redhat.com> wrote: > On linux systems, the initial start of openvswitch attempts to load > the openvswitch.ko kernel module. This module allows openvswitch to > utilize the kernel datapath. > > Some of these linux systems, notably Fedora and RHEL, use selinux to > enforce additional restrictions on various processes by way of allowing > or disallowing access from a specific selinux domain to a particular > operation on an selinux type. On these systems, the openvswitch > initialization will be run from the 'openvswitch_t' selinux domain. > Attempts by a process in the 'openvswitch_t' selinux domain to load a > kernel module will be denied. > > One solution would be to simply allow 'openvswitch_t' to load a kernel > directly. This essentially means that 'openvswitch_t' would really be > 'unconfined_t' - since an attacker that can control the code can issue > a kernel load. > > The solution implemented here uses a labeled file in the openvswitch > scripts directory, which is writable only by root. That file will force > a domain transition to the 'openvswitch_load_module_t' domain. The > 'openvswitch_load_module_t' domain will then be granted permissions to > load a kernel module. > > Please vet the new permissions in 2/4 *carefully*. I've tried to keep > it as restricted as possible. If there are any useful selinux interfaces > that would simplify the permission grants needed for the new domain, I'm > happy to spin a v2. Thanks for doing this. At high level this seems promising to me. I will review it over the weekend and let you know my feedback. > > Aaron Conole (4): > ovs-kmod-ctl: introduce a kernel module load script > selinux: create a transition type for module loading > selinux: introduce domain transitioned kmod helper > rhel: selinux-policy to invoke proper label macros > > debian/openvswitch-switch.install | 1 + > debian/openvswitch-switch.manpages | 1 + > rhel/openvswitch-fedora.spec.in | 12 +- > rhel/openvswitch.spec.in | 2 + > selinux/.gitignore | 4 + > selinux/automake.mk | 3 +- > selinux/openvswitch-custom.fc.in | 1 + > selinux/openvswitch-custom.te.in | 79 ++++++++++++- > utilities/.gitignore | 1 + > utilities/automake.mk | 5 + > utilities/ovs-ctl.in | 32 +----- > utilities/ovs-kmod-ctl.8 | 103 +++++++++++++++++ > utilities/ovs-kmod-ctl.in | 228 +++++++++++++++++++++++++++++++++++++ > utilities/ovs-lib.in | 12 +- > 14 files changed, 439 insertions(+), 45 deletions(-) > create mode 100644 selinux/openvswitch-custom.fc.in > create mode 100644 utilities/ovs-kmod-ctl.8 > create mode 100644 utilities/ovs-kmod-ctl.in > > -- > 2.14.3 >