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

[Eric Paris]

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)

-Eric