On Wed, Jun 27, 2012 at 9:25 PM, Anthony Liguori <address@hidden>
wrote:
On 06/21/2012 03:04 AM, Avi Kivity wrote:
On 06/19/2012 09:58 PM, Blue Swirl wrote:
At least qemu-ifup/down scripts, migration exec and smbd have been
mentioned. Only the system calls made by smbd (for some version of
it)
can be known. The user could specify arbitrary commands for the
others, those could be assumed to use some common (large) subset of
system calls but I think the security value would be close to zero
then.
We're not trying to protect against the user, but against the guest.
If
we assume the user wrote those scripts with care so they cannot be
exploited by the guest, then we are okay.
My concern was that first we could accidentally filter a system call
that changes the script or executable behavior, much like sendmail +
capabilities bug, and then a guest could trigger running this
script/executable and exploit the changed behavior.
Ah, I see. I agree this is dangerous. We should probably disable exec
if we seccomp.
There's no great place to jump into this thread so I guess I'll do it
here.
There is absolutely no doubt that white-listing syscalls that we
currently
use provides an improvement in security.
We need to assume:
1) QEMU is run as an unprivileged user
2) QEMU is already heavily restricted by SELinux
In this case, seccomp() is not being used to replace MAC or DAC. It's
supplementing both of them by additionally filtering out syscalls that
may
have unknown kernel exploits in them. That's all this initial effort is
about. Since it's scope is so limited, we can simply enable it
unconditionally too.
I don't think the scope is limited in a safe way. What is the set of
system calls that can't ever cause problems to any possible ifup/down
scripts, migration exec helpers and various versions of smbd?
For example, unlink() is missing. What if the ifup/down script needs
it for lock file cleanup? ftruncate()? Every socket syscalls in case
LDAP is used to access user information by the libc?
I think we can't define the safe set, except 'allow all'. I'd propose
one of the following to avoid breakage:
1. Allow all system calls for the initial patch, refactor later to
reduce the set. Useless until refactored.
2. Don't make seccomp mode enabled default, when enabled, forbid
execve(). Limits functionality when enabled, no security benefit if
not enabled.