Thanks. How are the rules managed so as to fit the VM system calls? Is tuning possible? recommended? Regards, 2014-12-09 17:32 GMT+01:00 Michal Privoznik <mprivozn@redhat.com>:

On 09.12.2014 15:24, Raymond Durand wrote:

...

How is libseccomp used/enabled/configured with KVM/QEMU Hypervisor?

You need to set seccomp_sandbox=1 in /etc/libvirt/qemu.conf and restart libvirtd. From now on, any qemu/kvm guest that libvirt starts will use seccomp or fail if qemu binary doesn't support it.

Michal

On 12/12/2014 10:32 AM, Daniel P. Berrange wrote:

On Fri, Dec 12, 2014 at 04:24:55PM +0100, Raymond Durand wrote:

...

Thanks.

How are the rules managed so as to fit the VM system calls? Is tuning possible? recommended? QEMU has a built-in policy that adds rules for every conceivable function that QEMU might need to execute. Given that is quite broad, the security benefit from seccomp enablement is quit low IMHO

Base code and (active) devices would each have to report what syscalls they need so this list could be reduced to the minimum ... Stefan

Regards, Daniel

On 12/12/2014 12:13 PM, Raymond Durand wrote:

Thanks.

2014-12-12 17:06 GMT+01:00 Stefan Berger <stefanb@linux.vnet.ibm.com <mailto:stefanb@linux.vnet.ibm.com>>:

On 12/12/2014 10:32 AM, Daniel P. Berrange wrote:

On Fri, Dec 12, 2014 at 04:24:55PM +0100, Raymond Durand wrote:

Thanks.

How are the rules managed so as to fit the VM system calls? Is tuning possible? recommended?

QEMU has a built-in policy that adds rules for every conceivable function that QEMU might need to execute. Given that is quite broad, the security benefit from seccomp enablement is quit low IMHO

Base code and (active) devices would each have to report what syscalls they need so this list could be reduced to the minimum ...

"Could be reduced": how? do you have in mind by selecting the appropriate active devices at the initialization time?

The difficulty would be to determine which devices require which syscalls beyond what 'base' QEMU needs (= QEMU without devices). So one would have to use QEMU with one device after another and see which new syscalls are required due to a specific device (syscall auditing), then add the array of syscalls to a device's TypeInfo structure and collect them this way. If a device's code was to change, you'd have to do it again. So I think it would be a lot of work all the time. Stefan

Stefan

Regards, Daniel

-- libvir-list mailing list libvir-list@redhat.com <mailto:libvir-list@redhat.com> https://www.redhat.com/mailman/listinfo/libvir-list

Regards,

On Fri, Dec 12, 2014 at 06:12:40PM +0100, Raymond Durand wrote:

Thanks.

2014-12-12 16:32 GMT+01:00 Daniel P. Berrange <berrange@redhat.com>:

...

On Fri, Dec 12, 2014 at 04:24:55PM +0100, Raymond Durand wrote:

...

Thanks.

How are the rules managed so as to fit the VM system calls? Is tuning possible? recommended?

QEMU has a built-in policy that adds rules for every conceivable function that QEMU might need to execute. Given that is quite broad, the security benefit from seccomp enablement is quit low IMHO

I see. Is it something like each QEMU device enabled comes along with a system-calls list ie. rules allowed? Is this list of rules loaded at each time the QEMU/KVM starts?

No, the list of rules was jsut figured out by trial & error, launching QEMU with more rules until it stopped crashing with all tested configs. No one has tried to figure out fine grained rules as it is an enourmous task Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|