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

Eric Sesterhenn eric.sesterhenn at lsexperts.de
Thu Jul 17 06:36:52 UTC 2014


On 07/16/2014 08:04 PM, Ben Pfaff wrote:
> On Wed, Jul 16, 2014 at 02:53:37PM -0300, Flavio Leitner wrote:
>> On Wed, Jul 16, 2014 at 09:56:20AM -0700, Ben Pfaff wrote:
>>> On Wed, Jul 16, 2014 at 10:39:17AM -0300, Flavio Leitner wrote:
>>> There's more than one way to chroot.  Maybe Eric is thinking of a
>>> model where one chroots to an empty directory, after opening all the
>>> files that one needs.  But I don't think he really explained the
>>> model.
>>
>> That's true and it looks like ovsdb-server doesn't need to re-open it.
>>
>> But that apparently won't work for vswitchd without breaking tap
>> devices support.


thats the reason why i looked at the ovsdb-server first.

My intent was to reduce the privileges by putting it into an
empty chroot, after all required files are opened. In order to make
sure, that an attacker can not do much inside this chroot, it is checked,
that the chroot is non-writeable.

A second step might be to drop further capabilities by employing seccomp
to reduce the number of allowed system calls to the minimum required.

>> I am by no means against the empty chroot idea.
> 
> vswitchd has multiple needs for special privileges.  It opens tap
> devices and other network devices, it needs privileged access to
> netlink sockets, it can modify network device IP addresses and the
> routing table (admittedly not important features these days), it has
> SSL private keys, etc.  And most of those can change at runtime when
> the database gets updated.
> 
> A thought I've had about hardening ovs-vswitchd is to adopt an
> OpenSSH-like privilege separation model, where a simple, separate
> process with high privilege doles out restricted access to resources
> as necessary to the main process over an RPC-based API.

That would be the best option, other projects like vsftpd do this as well,
since the attacker requires a bug in the RPC mechanism or the kernel
to escape the sandbox.

Best regards,
Eric

-- 
LSE Leading Security Experts GmbH, Postfach 100121, 64201 Darmstadt
Unternehmenssitz: Weiterstadt, Amtsgericht Darmstadt: HRB8649
Geschäftsführer: Oliver Michel, Sven Walther



More information about the dev mailing list