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

[NoxDaFox]

2017-02-21 16:32 GMT+02:00 Pino Toscano <ptoscano at redhat.com>:

> 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
>

Streaming APIs might be very useful indeed but the use case I have in mind
is a bit different.

The advantage of having tools such as Yara, Grep, Hivex and Libmagic
integrated within libguestfs is the added security layer.

Exploits are data driven, the way such data is accessed does not matter.
What matter is where that data is accessed.
Streaming the data out from libguestfs would not bring great benefits
neither performance nor security wise.
It might actually increase the attack surface as the vulnerability could
hide both on the tool and on libguestfs streaming interface.

IMHO a non intrusive integration altogether with plugin-type packages would
bring the best benefit to the Users.
 - libguestfs
 - libguestfs-forensics
 - libguestfs-recovery
 - ...

If I'm not mistaken, libguestfs already supports such architecture.


--
> Pino Toscano
> _______________________________________________
> Libguestfs mailing list
> Libguestfs at redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20170221/3f5a5856/attachment.htm>