On Mon, Jul 2, 2012 at 6:05 PM, Corey Bryant wrote:
>
>
> On 06/28/2012 03:49 PM, Blue Swirl wrote:
>>
>> On Wed, Jun 27, 2012 at 9:25 PM, Anthony Liguori
>> wrote:
>>>
>>> On 06/21/2012 03:04 AM, Avi Kivity wrote:
On 06/19/2012 09:58 PM, Blue Swirl wrote:
>>>
>>>
>>> A
On 06/28/2012 03:49 PM, Blue Swirl wrote:
On Wed, Jun 27, 2012 at 9:25 PM, Anthony Liguori wrote:
On 06/21/2012 03:04 AM, Avi Kivity wrote:
On 06/19/2012 09:58 PM, Blue Swirl wrote:
At least qemu-ifup/down scripts, migration exec and smbd have been
mentioned. Only the system calls made by
On 07/01/2012 10:18 PM, Will Drewry wrote:
On Sun, Jul 1, 2012 at 8:25 AM, Paolo Bonzini wrote:
Il 18/06/2012 23:53, Corey Bryant ha scritto:
Can each thread have separate seccomp whitelists? For example CPU
threads should not need pretty much anything but the I/O thread needs
I/O.
No, s
On Sun, Jul 1, 2012 at 8:25 AM, Paolo Bonzini wrote:
> Il 18/06/2012 23:53, Corey Bryant ha scritto:
>>>
>>> Can each thread have separate seccomp whitelists? For example CPU
>>> threads should not need pretty much anything but the I/O thread needs
>>> I/O.
>>>
>>
>> No, seccomp filters are define
Il 18/06/2012 23:53, Corey Bryant ha scritto:
>>
>> Can each thread have separate seccomp whitelists? For example CPU
>> threads should not need pretty much anything but the I/O thread needs
>> I/O.
>>
>
> No, seccomp filters are defined and enforced at the process level.
Perhaps we can add (at t
On 06/29/2012 04:00 PM, Blue Swirl wrote:
On Fri, Jun 29, 2012 at 3:27 PM, Corey Bryant wrote:
On 06/28/2012 03:49 PM, Blue Swirl wrote:
On Wed, Jun 27, 2012 at 9:25 PM, Anthony Liguori
wrote:
On 06/21/2012 03:04 AM, Avi Kivity wrote:
On 06/19/2012 09:58 PM, Blue Swirl wrote:
At
On Fri, Jun 29, 2012 at 3:27 PM, Corey Bryant wrote:
>
>
> On 06/28/2012 03:49 PM, Blue Swirl wrote:
>>
>> On Wed, Jun 27, 2012 at 9:25 PM, Anthony Liguori
>> wrote:
>>>
>>> On 06/21/2012 03:04 AM, Avi Kivity wrote:
On 06/19/2012 09:58 PM, Blue Swirl wrote:
>>>
>>>
>>>
On 06/28/2012 03:49 PM, Blue Swirl wrote:
On Wed, Jun 27, 2012 at 9:25 PM, Anthony Liguori wrote:
On 06/21/2012 03:04 AM, Avi Kivity wrote:
On 06/19/2012 09:58 PM, Blue Swirl wrote:
At least qemu-ifup/down scripts, migration exec and smbd have been
mentioned. Only the system calls made by
On Wed, Jun 27, 2012 at 9:25 PM, Anthony Liguori wrote:
> On 06/21/2012 03:04 AM, Avi Kivity wrote:
>>
>> On 06/19/2012 09:58 PM, Blue Swirl wrote:
>
> At least qemu-ifup/down scripts, migration exec and smbd have been
> mentioned. Only the system calls made by smbd (for some version o
On 06/21/2012 03:04 AM, Avi Kivity wrote:
On 06/19/2012 09:58 PM, Blue Swirl wrote:
At least qemu-ifup/down scripts, migration exec and smbd have been
mentioned. Only the system calls made by smbd (for some version of it)
can be known. The user could specify arbitrary commands for the
others, th
On 06/19/2012 09:58 PM, Blue Swirl wrote:
>>> At least qemu-ifup/down scripts, migration exec and smbd have been
>>> mentioned. Only the system calls made by smbd (for some version of it)
>>> can be known. The user could specify arbitrary commands for the
>>> others, those could be assumed to use s
On Tue, Jun 19, 2012 at 11:04 AM, Avi Kivity wrote:
> On 06/16/2012 09:46 AM, Blue Swirl wrote:
>> On Fri, Jun 15, 2012 at 9:36 PM, Paul Moore wrote:
>>> On Friday, June 15, 2012 09:23:46 PM Blue Swirl wrote:
On Fri, Jun 15, 2012 at 9:02 PM, Paul Moore wrote:
> On Friday, June 15, 2012
On Tue, Jun 19, 2012 at 9:23 AM, Daniel P. Berrange wrote:
> On Mon, Jun 18, 2012 at 08:15:37PM +, Blue Swirl wrote:
>> On Mon, Jun 18, 2012 at 8:31 AM, Daniel P. Berrange
>> wrote:
>> > On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote:
>> >> On Friday, June 15, 2012 07:06:10 PM Bl
On 06/19/2012 11:37 AM, Will Drewry wrote:
On Tue, Jun 19, 2012 at 8:35 AM, Corey Bryant wrote:
On 06/18/2012 06:14 PM, Will Drewry wrote:
[-all]
On Mon, Jun 18, 2012 at 4:53 PM, Corey Bryant
wrote:
On 06/18/2012 04:18 PM, Blue Swirl wrote:
On Mon, Jun 18, 2012 at 3:22 PM, Corey
On 06/16/2012 09:46 AM, Blue Swirl wrote:
> On Fri, Jun 15, 2012 at 9:36 PM, Paul Moore wrote:
>> On Friday, June 15, 2012 09:23:46 PM Blue Swirl wrote:
>>> On Fri, Jun 15, 2012 at 9:02 PM, Paul Moore wrote:
>>> > On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
>>> >> I think allowing exec
On Mon, Jun 18, 2012 at 08:15:37PM +, Blue Swirl wrote:
> On Mon, Jun 18, 2012 at 8:31 AM, Daniel P. Berrange
> wrote:
> > On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote:
> >> On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
> >> > I think allowing execve() would render secc
On 06/18/2012 04:18 PM, Blue Swirl wrote:
On Mon, Jun 18, 2012 at 3:22 PM, Corey Bryant wrote:
On 06/18/2012 04:33 AM, Daniel P. Berrange wrote:
On Fri, Jun 15, 2012 at 07:04:45PM +, Blue Swirl wrote:
On Wed, Jun 13, 2012 at 8:33 PM, Daniel P. Berrange
wrote:
On Wed, Jun 13, 2012
On Mon, Jun 18, 2012 at 8:13 PM, Eduardo Otubo wrote:
> On Mon, Jun 18, 2012 at 02:55:35PM +0100, Daniel P. Berrange wrote:
>> On Mon, Jun 18, 2012 at 09:52:44AM -0400, Paul Moore wrote:
>> > On Monday, June 18, 2012 09:31:03 AM Daniel P. Berrange wrote:
>> > > On Fri, Jun 15, 2012 at 05:02:19PM -
On Mon, Jun 18, 2012 at 3:22 PM, Corey Bryant wrote:
>
>
> On 06/18/2012 04:33 AM, Daniel P. Berrange wrote:
>>
>> On Fri, Jun 15, 2012 at 07:04:45PM +, Blue Swirl wrote:
>>>
>>> On Wed, Jun 13, 2012 at 8:33 PM, Daniel P. Berrange
>>> wrote:
On Wed, Jun 13, 2012 at 07:56:06PM +,
On Mon, Jun 18, 2012 at 8:31 AM, Daniel P. Berrange wrote:
> On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote:
>> On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
>> > I think allowing execve() would render seccomp pretty much useless.
>>
>> Not necessarily.
>>
>> I'll agree that i
On Mon, Jun 18, 2012 at 02:55:35PM +0100, Daniel P. Berrange wrote:
> On Mon, Jun 18, 2012 at 09:52:44AM -0400, Paul Moore wrote:
> > On Monday, June 18, 2012 09:31:03 AM Daniel P. Berrange wrote:
> > > On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote:
> > > > On Friday, June 15, 2012 07:
On 06/16/2012 02:46 AM, Blue Swirl wrote:
On Fri, Jun 15, 2012 at 9:36 PM, Paul Moore wrote:
On Friday, June 15, 2012 09:23:46 PM Blue Swirl wrote:
On Fri, Jun 15, 2012 at 9:02 PM, Paul Moore wrote:
On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
I think allowing execve() would ren
On 06/18/2012 04:31 AM, Daniel P. Berrange wrote:
On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote:
On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
I think allowing execve() would render seccomp pretty much useless.
Not necessarily.
I'll agree that it does seem a bit odd t
On 06/18/2012 04:33 AM, Daniel P. Berrange wrote:
On Fri, Jun 15, 2012 at 07:04:45PM +, Blue Swirl wrote:
On Wed, Jun 13, 2012 at 8:33 PM, Daniel P. Berrange wrote:
On Wed, Jun 13, 2012 at 07:56:06PM +, Blue Swirl wrote:
On Wed, Jun 13, 2012 at 7:20 PM, Eduardo Otubo wrote:
I adde
On Monday, June 18, 2012 02:55:35 PM Daniel P. Berrange wrote:
> On Mon, Jun 18, 2012 at 09:52:44AM -0400, Paul Moore wrote:
> > On Monday, June 18, 2012 09:31:03 AM Daniel P. Berrange wrote:
> > > On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote:
> > > > On Friday, June 15, 2012 07:06:10
On Mon, Jun 18, 2012 at 09:52:44AM -0400, Paul Moore wrote:
> On Monday, June 18, 2012 09:31:03 AM Daniel P. Berrange wrote:
> > On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote:
> > > On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
> > > > I think allowing execve() would render se
On Monday, June 18, 2012 09:31:03 AM Daniel P. Berrange wrote:
> On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote:
> > On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
> > > I think allowing execve() would render seccomp pretty much useless.
> >
> > Not necessarily.
> >
> > I'll a
On Mon, Jun 18, 2012 at 09:31:03AM +0100, Daniel P. Berrange wrote:
> On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote:
> > On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
> > > I think allowing execve() would render seccomp pretty much useless.
> >
> > Not necessarily.
> >
> > I
On Fri, Jun 15, 2012 at 07:04:45PM +, Blue Swirl wrote:
> On Wed, Jun 13, 2012 at 8:33 PM, Daniel P. Berrange
> wrote:
> > On Wed, Jun 13, 2012 at 07:56:06PM +, Blue Swirl wrote:
> >> On Wed, Jun 13, 2012 at 7:20 PM, Eduardo Otubo
> >> wrote:
> >> > I added a syscall struct using priori
On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote:
> On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
> > I think allowing execve() would render seccomp pretty much useless.
>
> Not necessarily.
>
> I'll agree that it does seem a bit odd to allow execve(), but there is still
> val
On Fri, Jun 15, 2012 at 07:06:10PM +, Blue Swirl wrote:
> On Wed, Jun 13, 2012 at 8:30 PM, Daniel P. Berrange
> wrote:
> > On Wed, Jun 13, 2012 at 04:20:22PM -0300, Eduardo Otubo wrote:
> >> I added a syscall struct using priority levels as described in the
> >> libseccomp man page. The prior
On Fri, Jun 15, 2012 at 9:36 PM, Paul Moore wrote:
> On Friday, June 15, 2012 09:23:46 PM Blue Swirl wrote:
>> On Fri, Jun 15, 2012 at 9:02 PM, Paul Moore wrote:
>> > On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
>> >> I think allowing execve() would render seccomp pretty much useless.
>
On 06/15/2012 03:23 PM, Blue Swirl wrote:
> How about seccomp mode selected by command line switch -seccomp, in
> which bind/connect/open/execve are forbidden? The functionality
> remaining would be somewhat limited (can't migrate or use SMB etc.
More properly, can't migrate with exec:command mig
On Friday, June 15, 2012 09:23:46 PM Blue Swirl wrote:
> On Fri, Jun 15, 2012 at 9:02 PM, Paul Moore wrote:
> > On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
> >> I think allowing execve() would render seccomp pretty much useless.
> >
> > Not necessarily.
> >
> > I'll agree that it does
On Fri, Jun 15, 2012 at 9:02 PM, Paul Moore wrote:
> On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
>> I think allowing execve() would render seccomp pretty much useless.
>
> Not necessarily.
>
> I'll agree that it does seem a bit odd to allow execve(), but there is still
> value in enabli
On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
> I think allowing execve() would render seccomp pretty much useless.
Not necessarily.
I'll agree that it does seem a bit odd to allow execve(), but there is still
value in enabling seccomp to disable potentially buggy/exploitable syscalls.
On Wed, Jun 13, 2012 at 8:30 PM, Daniel P. Berrange wrote:
> On Wed, Jun 13, 2012 at 04:20:22PM -0300, Eduardo Otubo wrote:
>> I added a syscall struct using priority levels as described in the
>> libseccomp man page. The priority numbers are based to the frequency
>> they appear in a sample strac
On Wed, Jun 13, 2012 at 8:33 PM, Daniel P. Berrange wrote:
> On Wed, Jun 13, 2012 at 07:56:06PM +, Blue Swirl wrote:
>> On Wed, Jun 13, 2012 at 7:20 PM, Eduardo Otubo
>> wrote:
>> > I added a syscall struct using priority levels as described in the
>> > libseccomp man page. The priority numb
On Wed, Jun 13, 2012 at 04:20:22PM -0300, Eduardo Otubo wrote:
> I added a syscall struct using priority levels as described in the
> libseccomp man page. The priority numbers are based to the frequency
> they appear in a sample strace from a regular qemu guest run under
> libvirt.
>
> Libseccomp
On Wed, Jun 13, 2012 at 04:20:22PM -0300, Eduardo Otubo wrote:
> I added a syscall struct using priority levels as described in the
> libseccomp man page. The priority numbers are based to the frequency
> they appear in a sample strace from a regular qemu guest run under
> libvirt.
>
> Libseccomp
On Wed, Jun 13, 2012 at 07:56:06PM +, Blue Swirl wrote:
> On Wed, Jun 13, 2012 at 7:20 PM, Eduardo Otubo
> wrote:
> > I added a syscall struct using priority levels as described in the
> > libseccomp man page. The priority numbers are based to the frequency
> > they appear in a sample strace
On Wed, Jun 13, 2012 at 7:20 PM, Eduardo Otubo wrote:
> I added a syscall struct using priority levels as described in the
> libseccomp man page. The priority numbers are based to the frequency
> they appear in a sample strace from a regular qemu guest run under
> libvirt.
>
> Libseccomp generates
I added a syscall struct using priority levels as described in the
libseccomp man page. The priority numbers are based to the frequency
they appear in a sample strace from a regular qemu guest run under
libvirt.
Libseccomp generates linear BPF code to filter system calls, those rules
are read one
43 matches
Mail list logo
