Re: [Libguestfs] [PATCH v3 0/7] Feature: Yara file scanning
2017-02-20 12:26 GMT+02:00 Daniel P. Berrange <berrange(a)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/
:|
Attachments:
- attachment.html (text/html — 3.6 KB)