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

[Dor Laor <dlaor@redhat.com>]

On 12/08/2011 11:40 AM, Stefan Hajnoczi wrote:
> On Wed, Dec 7, 2011 at 8:54 PM, Eric Paris<eparis@redhat.com>  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?

>
> Stefan
>