2017-02-20 12:26 GMT+02:00 Daniel P. Berrange <berra...@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/ > :| >
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs