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

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.

A vulnerability within the Yara scanner might lead to the host being
exposed. This is one of the reasons libguestfs is a good tool for helping
disk forensics as it adds a layer of protection against exploits.
More information here:
http://libguestfs.org/guestfs-security.1.html
https://pythonhosted.org/vminspect/#design-principles

Moreover, the fuse FS brings performance impacts which might be
considerable if we want to scan an entire FS or set of folders.
http://libguestfs.org/guestfs.3.html#mount-local

>
> Perhaps there's performance benefits todoing it by adding new APIs ?
> If so do you have any info on the scale of the benefit ?
>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org              -o-             http://virt-manager.org
> :|
> |: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/
> :|
>

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

-- 
Pino Toscano

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
>