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

[Will Drewry]

On Sun, Dec 11, 2011 at 4:50 AM, Dor Laor <address@hidden> wrote:
> 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?

Hi - yup. I keep getting delayed with other work, but I still plan to
send it soon.  The first plan was to port the updated patchset to
linus's tree, then repost. I plan on adding a cover letter (0/x) to
the series to see if we can get discussion going again on it. I'm not
sure what the merge chance is, to be honest. I believe the patch is
desirable to many parties, but Ingo didn't feel it was appropriate
given that it would add an ABI that was not part of the trace/perf
ABI.  Given that grand-unified trace has been held up on stable
internal api points and other challenges, I would hope that we could
continue on using a prctl for seccomp_filter, even if it becomes a
compatibility layer which is eventually switched off for most users.

I did spend some time looking at other approaches (making the syscall
table a namespace, cgroups syscalls like Łukasz Sowa's patch, etc),
but using the seccomp-centered approach still seems to make sense from
a process view and a seccomp view - and who wants a new syscall anyway
:)  The last thing I am looking at before I post is seeing if  it'd be
possible to avoid touching ftrace filter engine at all for
ipc,socketcall, ioctl, etc, but I'm not sure that it makes sense to
not use the generic system that exists today.

cheers!
will