qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 00/11] Adding FreeBSD's Capsicum security fr


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH 00/11] Adding FreeBSD's Capsicum security framework (part 1)
Date: Mon, 07 Jul 2014 14:20:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

Il 07/07/2014 12:29, David Drysdale ha scritto:
I think that's more easily done by opening the file as O_RDONLY/O_WRONLY
/O_RDWR.   You could do it by running the file descriptor's seccomp-bpf
program once per iocb with synthesized syscall numbers and argument
vectors.

Right, but generating the equivalent seccomp input environment for an
equivalent single-fd syscall is going to be subtle and complex (which
are worrying words to mention in a security context).  And how many
other syscalls are going to need similar special-case processing?
(poll? select? send[m]msg? ...)

Yeah, the difficult part is getting the right balance between:

1) limitations due to seccomp's impossibility to chase pointers (which is not something that can be lifted, as it's required for correctness)

2) subtlety and complexity of the resulting code.

The problem stems when you have a single a single syscall operating on multiple file descriptors. So for example among the cases you mention poll and select are problematic; sendm?msg are not. They would be if Capsicum had a capability for SCM_RIGHTS file descriptor passing, but I cannot find it.

But then you also have to strike the right balance between a complete solution and an overengineered one.

For example, even though poll and select are problematic, I wonder what would really the point be in blocking them; poll/select are level-triggered, and calling them should be idempotent as far as the file descriptor is concerned. If you want to prevent a process/thread from issuing blocking system calls, but you'd do that with a per-process filter, not with per-file-descriptor filters or capabilities.

Capsicum capabilities are associated with the file descriptor (a la
F_GETFD), not the open file itself -- different FDs with different
associated rights can map to the same underlying open file.

Good to know, thanks.  I suppose you have testcases that cover this.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]