[Top][All Lists]

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

Re: [Qemu-devel] [RFC] Device sandboxing

From: Dor Laor
Subject: Re: [Qemu-devel] [RFC] Device sandboxing
Date: Sun, 11 Dec 2011 12:50:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 12/08/2011 11:40 AM, Stefan Hajnoczi wrote:
On Wed, Dec 7, 2011 at 8:54 PM, Eric Paris<address@hidden>  wrote:
On Wed, 2011-12-07 at 13:43 -0600, Anthony Liguori wrote:
On 12/07/2011 01:32 PM, Corey Bryant wrote:

That would seem like the logical approach. I think there may be new mode 2
patches coming soon so we can see how they go over.

I'd like to see what the whitelist would need to be for something like QEMU in
mode 2.  My biggest concern is that the whitelist would need to be so large that
the practical security what's all that much improved.

When I prototyped my version of seccomp v2 for qemu a while back I did
it by only looking at syscalls after inital setup was completed (aka the
very last thing before main_loop() was to lock it down).  My list was
much sorter than even these:

+        __NR_brk,
+        __NR_close,
+        __NR_exit_group,
+        __NR_futex,
+        __NR_ioctl,
+        __NR_madvise,
+        __NR_mmap,
+        __NR_munmap,
+        __NR_read,
+        __NR_recvfrom,
+        __NR_recvmsg,
+        __NR_rt_sigaction,
+        __NR_select,
+        __NR_sendto,
+        __NR_tgkill,
+        __NR_timer_delete,
+        __NR_timer_gettime,
+        __NR_timer_settime,
+        __NR_write,
+        __NR_writev,

There is simple obvious negligible overhead value here, but every
proposal I know of, including mine, has been shot down by Ingo.  Ingo's
proposal is much more work, more overhead, but clearly more flexible.
His suggestions (and code based on those suggestions from others) has
been shot down by PeterZ.

So I feel like seccomp v2 is between a rock and a hard place.  We have
something that works really well, and could be a huge win for all sorts
of programs, but we don't seem to be able to get anything past the
damned if you do, damned if you don't nak's.....

(There's also a cgroup version of seccomp proposed, but I'm guessing it
will go just about as far as all the other versions)

Still, these sorts of situations are overcome all the time.  Sometimes
it takes a while and several LWN.net articles about the drama but at
the end things can be worked out.

If we want to discuss the specifics of mode 2 and especially what Ingo
or Peter think then I think we should do it in a forum where they
participate.  Maybe their positions have changed.

Will, little bird whispered that you'll going to send another iteration w/ higher acceptance chances. Where do we stand w/ it? Can you please elaborate on it chance to get merged?


reply via email to

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