On Monday, 20 February 2017 13:46:29 CET NoxDaFox wrote:
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.
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