[ovs-dev] [PATCH] bridge: allow OVS to connect to Unix Domain Sockets outside its run directory

Wed Jun 8 23:45:34 UTC 2016

On 8 June 2016 at 14:02, Ben Pfaff <blp at ovn.org> wrote:

> On Thu, Jun 02, 2016 at 07:47:33PM -0700, Ansis Atteka wrote:
> > Before this patch OVS refused to connect to a local controller that
> > had its Unix Domain Socket outside Open vSwitch run directory (e.g.
> > outside '/var/run/openvswitch/').
> >
> > After this patch this restriction imposed by Open vSwitch itself is
> > abandoned and OVS should be able to connect to controller's Unix Domain
> > Sockets anywhere under filesystem.
>
> When I run "netstat -lnx" on my laptop, I see a bunch of listening Unix
> domain sockets.
>

> Some of these listening sockets are security sensitive, such as SSH
> agents, so it wouldn't be good to have a remote manager be able to point
> OVS to them: what if a clever person could figure out how to send
> arbitrary data to them (maybe in a packet-in message somehow?) via
> OpenFlow.  Other examples are dbus and udev sockets.
>
> That's my main worry here.
>

Ok, I see your concern now. At least with SELinux enabled such attacks
would fail on default Fedora, RHEL and CentOS:

because Open vSwitch runs under openvswitch_t domain:

system_u:system_r:openvswitch_t:s0 root  16567 16566  0 66914 36460   0
15:51 ?        00:00:00 ovs-vswitchd unix:/var/run/openvswitch/db.sock
-vconsole:emer -vsyslog:err -vfile:info --mlockall --no-chdir
--log-file=/var/log/openvswitch/ovs-vswitchd.log
--pidfile=/var/run/openvswitch/ovs-vswitchd.pid --detach --monitor

and OVS is unable to connect sockets other than those that have type
openvswitch*_t type:

srwxr-x---. 1 root root system_u:object_r:openvswitch_var_run_t:s0 0 Jun  8
15:51 /var/run/openvswitch/brT.mgmt

For example, udev control socket and others use udev_var_run_t type:

srw-------. 1 root root system_u:object_r:udev_var_run_t:s0 0 Jun  2 15:43
/run/udev/control

So the problem my patch is trying to solve is that there could be over
confined processes trying

Here are the options I see:
1. abandon my patch and tell everyone to figure out on their own on how to
connect to Open vSwitch sockets under /var/run/openvswitch/ directory (e.g.
by changing group of /var/run/openvswitch or by opening socket while their
processes are running under root user and only after that they change the
user).
2. abandon my patch, but implement something similar to Aaron's DPDK socket
chown()/chmod() patch and tell others to use it.
3. abandon my patch, but implement some kind of access control inside
OVSDB. For example, the roles could be "local admin" and "remote
controller". "remote controller" should have limited access to certain
database files. This is non-trivial, but may be something to consider
long-term because OVSDB currently contains a lot of things to which access
is granted on all-or-nothing basis.
4. move forward with my patch, but allow to dynamically specify whitelist.
Obviously this whitelist must not be configurable through OVSDB because
then it loses its purpose.
5. move forward with my patch, but use Mandatory Access Control to specify
whitelist of paths to which OVS can connect to (this makes assumption that
MAC - SELinux or AppArmor - is up and running).

Unfortunately there is no silver bullet for this problem.