[ovs-dev] [PATCH 0/3][RFC] Implement a chroot for ovsdb-server

Ben Pfaff blp at nicira.com
Tue Jul 15 20:00:18 UTC 2014


On Fri, Jul 11, 2014 at 01:24:01PM +0200, Eric Sesterhenn wrote:
> on my debian installation, the ovsdb-server is running as root. Since I
> prefer to add additional mitigations for running services, I was looking
> into putting the ovsdb-server into a chroot and implemented it in the
> following three patches.
> 
> These patches are send as a request for comments, since there are still
> some issues left. The first patch introduces a file descriptor leak, and
> some testcases fail when the chroot is enabled (these are 1293 1294 1297
> 1298 1299 1301  ). If --run-command is passed, the chroot is not active,
> since the ovsdb-server requires to access further files.
> 
> Is this something worthwile pursuing or are there reasons, why chrooting
> was not already implemented for ovsdb-server?

I like the idea.

Would you intend to extend this to ovs-vswitchd?

ovsdb-server and ovs-vswitchd can be reconfigured at runtime to access
new files in the file system.  For example, they can be reconfigured
to access new SSL keys, or to connect to new Unix domain sockets.  I
am not sure how this works out with a chroot.

I am not sure that it makes more sense to pre-open a /dev/urandom file
descriptor than it does to put /dev/urandom into the chroot.

The chroot might need to have /dev/null in it.

OVS sometimes reads files in /proc.

It is not too hard, I think, to populate a chroot with all the files
needed to start a program.  Given that, does it make sense to make
ovsdb-server have a built-in chroot capability, instead of just
populating a chroot with the necessary files and launching from there?
There are tradeoffs, of course.



More information about the dev mailing list