qemu-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC] Device sandboxing
Date: Thu, 8 Dec 2011 09:40:18 +0000

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.

Stefan



reply via email to

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