On Monday, 20 February 2017 13:46:29 CET NoxDaFox wrote:
> 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.
> > 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.
IMHO the ideal way would be having yara access files inside disks using
libguestfs. libyara already has APIs for scanning files from different
input types, i.e. yr_rules_scan_* -- what is missing is a generic I/O
implementation, which could be easy to wire up using the existing
This would mean that:
a) disks are accessed only within libguestfs
b) the yara API accesses files normally
c) nothing is mounted on the host
Libguestfs mailing list
Libguestfs redhat com