[Libguestfs] [PATCH v3 0/7] Feature: Yara file scanning

[Pino Toscano]

On Monday, 20 February 2017 13:46:29 CET NoxDaFox wrote:
> 2017-02-20 12:26 GMT+02:00 Daniel P. Berrange <berrange at 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.

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
YR_STREAM stuff.

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

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20170221/9a7998ba/attachment.sig>