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

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&gt;: > > > 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 _______________________________________________ Libguestfs mailing list Libguestfs(a)redhat.com https://www.redhat.com/mailman/listinfo/libguestfs