2017-02-21 16:32 GMT+02:00 Pino Toscano <ptoscano@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@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@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs