2017-02-20 12:26 GMT+02:00 Daniel P. Berrange <berrange@redhat.com>:
On Sun, Feb 19, 2017 at 07:09:51PM +0200, Matteo Cafasso wrote:
> Rebase patches on top of 1.35.25.
>
> No changes since last series.

Can you explain the motivation behind adding the APis to libguestfs ?

Since the libguestfs VM is separate from the real VM, it can't
be relying on any live process state to scan for malicious code,
so must be exclusively considering the file contents.
 
This is the use case. For the former one, there are tools such as Rekall and Volatility which already do a great job.

http://www.rekall-forensic.com/
http://www.volatilityfoundation.org/


Could yara not simply use the existing libguestfs APIs to do its
work. At the simplest case this might be having the FS fuse mounted
at a location. Alternatively having it directly use the C API to
access content it needs would be safer against malicious symlinks.

There are both security and performance implication in using the FS fuse locally mounted.

A vulnerability within the Yara scanner might lead to the host being exposed. This is one of the reasons libguestfs is a good tool for helping disk forensics as it adds a layer of protection against exploits.
More information here:
http://libguestfs.org/guestfs-security.1.html
https://pythonhosted.org/vminspect/#design-principles

Moreover, the fuse FS brings performance impacts which might be considerable if we want to scan an entire FS or set of folders.
http://libguestfs.org/guestfs.3.html#mount-local
 

Perhaps there's performance benefits todoing it by adding new APIs ?
If so do you have any info on the scale of the benefit ?

Regards,
Daniel
--
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|