On 8 June 2016 at 17:17, Ansis Atteka <ansisatt...@gmail.com> wrote: > > > 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. >
This patch can be abandoned. I sent a new one with slightly different approach: http://openvswitch.org/pipermail/dev/2016-June/073211.html Basically it leaves the default behavior unchanged, but if one is running under SELinux or Apparmor, then he can disable the Self-confinement feature in OVS through /etc/default/openvswitch file. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
