[ovs-dev,v2,0/5] selinux: introduce a transition domain for loading kmods
mbox series

Message ID 20180504182818.24299-1-aconole@redhat.com
Headers show
Series
  • selinux: introduce a transition domain for loading kmods
Related show

Message

Aaron Conole May 4, 2018, 6:28 p.m. UTC
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.

The labelling won't take place until after the changes implemented in 4/4,
so it is really important to test the automatic labelling after that point.

v1->v2:
* Added a new commit to set the selinux-policy module version
* Added changes to the centos build in 4/4 to match the fedora build
* Fixed the manpage in 1/5


Aaron Conole (5):
  ovs-kmod-ctl: introduce a kernel module load script
  selinux: create a transition type for module loading
  selinux: tag the custom policy version
  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           |  12 +-
 selinux/.gitignore                 |   4 +
 selinux/automake.mk                |   3 +-
 selinux/openvswitch-custom.fc.in   |   1 +
 selinux/openvswitch-custom.te.in   |  81 ++++++++++++-
 utilities/.gitignore               |   1 +
 utilities/automake.mk              |   5 +
 utilities/ovs-ctl.in               |  32 +-----
 utilities/ovs-kmod-ctl.8           | 109 ++++++++++++++++++
 utilities/ovs-kmod-ctl.in          | 228 +++++++++++++++++++++++++++++++++++++
 utilities/ovs-lib.in               |  12 +-
 14 files changed, 454 insertions(+), 48 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

Comments

Ansis Atteka May 9, 2018, 11:37 p.m. UTC | #1
On Fri, 4 May 2018 at 11:28, 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.

> The labelling won't take place until after the changes implemented in 4/4,
> so it is really important to test the automatic labelling after that
point.

> v1->v2:
> * Added a new commit to set the selinux-policy module version
> * Added changes to the centos build in 4/4 to match the fedora build
> * Fixed the manpage in 1/5


Thanks. I wanted to test this on Fedora 27 too (with poc/builders), but I am
getting this error:

[root@fedoraubuilder x86_64]# yum install openvswitch-2.9.90-1.x86_64.rpm
Last metadata expiration check: 1:18:01 ago on Wed 09 May 2018 09:56:08 PM
UTC.
Error:
   Problem: conflicting requests
    - nothing provides /bin/python2 needed by openvswitch-2.9.90-1.x86_64
[root@fedoraubuilder x86_64]# /bin/python2 --version
Python 2.7.14
[root@fedoraubuilder x86_64]# rpm -q --whatprovides /bin/python
python2-2.7.14-10.fc27.x86_64
[root@fedoraubuilder x86_64]# rpm -qR  openvswitch-2.9.90-1.x86_64.rpm  |
grep -i python
/bin/python2

based on openvswitch-fedora.spec.in file my understanding is that it should
have picked python3 right? Though, I also have python2 so that error seems
strange to me.





> Aaron Conole (5):
>     ovs-kmod-ctl: introduce a kernel module load script
>     selinux: create a transition type for module loading
>     selinux: tag the custom policy version
>     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           |  12 +-
>    selinux/.gitignore                 |   4 +
>    selinux/automake.mk                |   3 +-
>    selinux/openvswitch-custom.fc.in   |   1 +
>    selinux/openvswitch-custom.te.in   |  81 ++++++++++++-
>    utilities/.gitignore               |   1 +
>    utilities/automake.mk              |   5 +
>    utilities/ovs-ctl.in               |  32 +-----
>    utilities/ovs-kmod-ctl.8           | 109 ++++++++++++++++++
>    utilities/ovs-kmod-ctl.in          | 228
+++++++++++++++++++++++++++++++++++++
>    utilities/ovs-lib.in               |  12 +-
>    14 files changed, 454 insertions(+), 48 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
Aaron Conole May 10, 2018, 1:32 p.m. UTC | #2
Ansis Atteka <ansisatteka@gmail.com> writes:

> On Fri, 4 May 2018 at 11:28, 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.
>
>> The labelling won't take place until after the changes implemented in 4/4,
>> so it is really important to test the automatic labelling after that
> point.
>
>> v1->v2:
>> * Added a new commit to set the selinux-policy module version
>> * Added changes to the centos build in 4/4 to match the fedora build
>> * Fixed the manpage in 1/5
>
>
> Thanks. I wanted to test this on Fedora 27 too (with poc/builders), but I am
> getting this error:
>
> [root@fedoraubuilder x86_64]# yum install openvswitch-2.9.90-1.x86_64.rpm
> Last metadata expiration check: 1:18:01 ago on Wed 09 May 2018 09:56:08 PM
> UTC.
> Error:
>    Problem: conflicting requests
>     - nothing provides /bin/python2 needed by openvswitch-2.9.90-1.x86_64
> [root@fedoraubuilder x86_64]# /bin/python2 --version
> Python 2.7.14
> [root@fedoraubuilder x86_64]# rpm -q --whatprovides /bin/python
> python2-2.7.14-10.fc27.x86_64
> [root@fedoraubuilder x86_64]# rpm -qR  openvswitch-2.9.90-1.x86_64.rpm  |
> grep -i python
> /bin/python2
>
> based on openvswitch-fedora.spec.in file my understanding is that it should
> have picked python3 right? Though, I also have python2 so that error seems
> strange to me.

I think it's related to the changes that went in with commit
db8dcbaf1c57 ("packaging: Make Fedora spec file CentOS compatible")
but I don't know for sure.

Timothy? Leif?

>> Aaron Conole (5):
>>     ovs-kmod-ctl: introduce a kernel module load script
>>     selinux: create a transition type for module loading
>>     selinux: tag the custom policy version
>>     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           |  12 +-
>>    selinux/.gitignore                 |   4 +
>>    selinux/automake.mk                |   3 +-
>>    selinux/openvswitch-custom.fc.in   |   1 +
>>    selinux/openvswitch-custom.te.in   |  81 ++++++++++++-
>>    utilities/.gitignore               |   1 +
>>    utilities/automake.mk              |   5 +
>>    utilities/ovs-ctl.in               |  32 +-----
>>    utilities/ovs-kmod-ctl.8           | 109 ++++++++++++++++++
>>    utilities/ovs-kmod-ctl.in          | 228
> +++++++++++++++++++++++++++++++++++++
>>    utilities/ovs-lib.in               |  12 +-
>>    14 files changed, 454 insertions(+), 48 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
Aaron Conole May 10, 2018, 5:08 p.m. UTC | #3
Ansis Atteka <ansisatteka@gmail.com> writes:

> On Fri, 4 May 2018 at 11:28, 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.
>
>> The labelling won't take place until after the changes implemented in 4/4,
>> so it is really important to test the automatic labelling after that
> point.
>
>> v1->v2:
>> * Added a new commit to set the selinux-policy module version
>> * Added changes to the centos build in 4/4 to match the fedora build
>> * Fixed the manpage in 1/5
>
>
> Thanks. I wanted to test this on Fedora 27 too (with poc/builders), but I am
> getting this error:
>
> [root@fedoraubuilder x86_64]# yum install openvswitch-2.9.90-1.x86_64.rpm
> Last metadata expiration check: 1:18:01 ago on Wed 09 May 2018 09:56:08 PM
> UTC.
> Error:
>    Problem: conflicting requests
>     - nothing provides /bin/python2 needed by openvswitch-2.9.90-1.x86_64
> [root@fedoraubuilder x86_64]# /bin/python2 --version
> Python 2.7.14
> [root@fedoraubuilder x86_64]# rpm -q --whatprovides /bin/python
> python2-2.7.14-10.fc27.x86_64
> [root@fedoraubuilder x86_64]# rpm -qR  openvswitch-2.9.90-1.x86_64.rpm  |
> grep -i python
> /bin/python2
>
> based on openvswitch-fedora.spec.in file my understanding is that it should
> have picked python3 right? Though, I also have python2 so that error seems
> strange to me.

Fyi - see:

https://mail.openvswitch.org/pipermail/ovs-dev/2018-May/346815.html

for an explanation on the reason.  I guess the POC ansible script
reorders the path and that causes the system to pick up something
incorrectly.  That's at least Timothy's explanation.

Try with that patch applied and see if it helps :)

>> Aaron Conole (5):
>>     ovs-kmod-ctl: introduce a kernel module load script
>>     selinux: create a transition type for module loading
>>     selinux: tag the custom policy version
>>     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           |  12 +-
>>    selinux/.gitignore                 |   4 +
>>    selinux/automake.mk                |   3 +-
>>    selinux/openvswitch-custom.fc.in   |   1 +
>>    selinux/openvswitch-custom.te.in   |  81 ++++++++++++-
>>    utilities/.gitignore               |   1 +
>>    utilities/automake.mk              |   5 +
>>    utilities/ovs-ctl.in               |  32 +-----
>>    utilities/ovs-kmod-ctl.8           | 109 ++++++++++++++++++
>>    utilities/ovs-kmod-ctl.in          | 228
> +++++++++++++++++++++++++++++++++++++
>>    utilities/ovs-lib.in               |  12 +-
>>    14 files changed, 454 insertions(+), 48 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