On 8 June 2016 at 16:45, Ansis Atteka <ansisatt...@gmail.com> wrote: > > > On 8 June 2016 at 14:02, Ben Pfaff <b...@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: > > [root@localhost ovs]# tail /var/log/openvswitch/ovs-vswitchd.log > 2016-06-08T22:51:48.215Z|00033|connmgr|INFO|brz: added service controller > "punix://var/run/openvswitch/brz.mgmt" > 2016-06-08T22:51:48.215Z|00034|bridge|INFO|bridge brs: using datapath ID > 0000e6d0bb7b3047 > 2016-06-08T22:51:48.215Z|00035|connmgr|INFO|brs: added service controller > "punix://var/run/openvswitch/brs.mgmt" > 2016-06-08T22:51:48.220Z|00036|bridge|INFO|ovs-vswitchd (Open vSwitch) > 2.5.90 > 2016-06-08T22:51:48.665Z|00037|rconn|INFO|brX<->unix:/run/udev/control: > connecting... > 2016-06-08T22:51:48.665Z|00038|rconn|WARN|brX<->unix:/run/udev/control: > connection failed (Permission denied) > 2016-06-08T22:51:48.665Z|00039|rconn|INFO|brX<->unix:/run/udev/control: > waiting 2 seconds before reconnect > 2016-06-08T22:51:50.666Z|00040|rconn|INFO|brX<->unix:/run/udev/control: > connecting... > 2016-06-08T22:51:50.666Z|00041|rconn|WARN|brX<->unix:/run/udev/control: > connection failed (Permission denied) > > 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 > Just noticed that my sentence was abruptly cut:
"So the problem my patch is trying to solve is that there could be over-confined processes trying to connect to OVS but they can't do that because /var/run/openvswitch and its contents are owned by root:root." > > 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- > s/database files/database tables or columns/ > 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. > > Actually, there may be a 6th solution: 6. move forward with my patch and hope that OpenFlow handshake would make the other side to close the socket early. This is still not that good as proper access control. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
