report in python, a first version

[Sébastien de Menten]

On Nov 16, 2016 12:30 AM, "John Ralls" <jralls at ceridwen.us> wrote:
>
>
> > On Nov 15, 2016, at 12:58 PM, Sébastien de Menten <sdementen at gmail.com>
wrote:
> >
> >
> > On Tue, Nov 15, 2016 at 6:41 PM, John Ralls <jralls at ceridwen.us> wrote:
> >
> > > On Nov 15, 2016, at 9:24 AM, Sébastien de Menten <sdementen at gmail.com>
wrote:
> > >
> > > On Tue, Nov 15, 2016 at 4:17 PM, John Ralls <jralls at ceridwen.us>
wrote:
> > >
> > > Sébastien,
> > >
> > > That's a bit more "external" than I had in mind. The plug/connect any
process part is a serious security issue.
> > >
> > > I don't understand the point of the json file. Users will want the
report to display and then to be able to open the report options dialog to
make changes like selecting a date range or modifying the accounts reported
on, and expect the report to regenerate when they click "Apply". ISTM to
accomplish that the report module needs to be in control and to pass to the
Python report-builder the options parameters. The second thing that won't
work is using PyCash: The user wants a report on what her book looks like
in memory, not what it looked like the last time she saved, so the report
will need to use the python bindings and connect to the current session.
> > >
> > > It looks to me from the Makefile.am that building guile-json requires
Guile-2.0, which you won't have if you're using the Guile in the GnuCash
Windows installation. You could try to simply copy the four .scm files into
share/guile/1.8/ and see if it works. It will only if the author didn't use
any Guile-2-only features.
> > >
> > > Regards,
> > > John Ralls
> > >
> > >
> > > On the security risk, it is no different than running the same
process outside GnuCash (in a terminal for instance), or is it ?
> > > The json file is there to be able to specify the options for a report
in a better way than writing Scheme in an scm file. Currently, for a given
python report (report_test.py), I generate the Scheme code wrapping this
python report (report_test.scm) with:
> > > - the proper Scheme code for the options defined in report_test.py
> > > - the proper Scheme code to call the python process (ie "python
report_test.py")
> > > Instead of having to generate scheme code, it would be better to have
a json file per report (report_test.json) that could be used to instantiate
the report in GnuCash.
> > >
> > > For piecash, there is no specific issue as the change in the book are
immediately serialised to the SQL backend. However, for the xml backend
(that piecash does not support anyway), the GnuCash file should be saved
before. But nothing forbids someone to use the official python bindings to
connect to the current session and do as you describe. However, how the
python bindings know to which session to connect if there are multiple
files opened at the same time ? and can they open a session in a separate
process while GnuCash has a lock on the file ?
> > >
> >
> > Sébastien,
> >
> > A process running outside GnuCash isn't pushing data into a running
instance of GnuCash, so yes, it's significantly different. The ancient
libwebkit we use has tons of known vulnerabilities that could be exploited
by injecting malicious HTML or JavaScript.
> >
> >
> > Any report written in guile can be malicious as it has (i guess) full
access to the OS (syscall, file manipulation, etc) and to the gnucash
engine (I guess the report could modify the book ... but I may be wrong).
Any outside process can tinker with the gnucash books to corrupt them. So I
do not see exactly what specific security threat would be avoided by
blocking the specific case of a process running outside Gnucash pushing a
string of HTML.
> >
> >
> > Maybe I misunderstand how the json file would work. Would it just
initialize the options which can then be edited in the report's options
dialog, or are the options in the json file the ones that the report gets
and the user must edit the json file in order to change them?
> >
> > Indeed, the json is just there to 1) initalise the 'options-generator'
object (with the options information), 2) specify the process to call (via
dynamic-wind) and 3) define the report (argument for 'gnc:define-report).
It is just way more readable/editable than tinkering with scm code. But we
could choose yaml (even more readable but must find a yaml parser for
guile) or xml (less readable but xml reader available in standard guile
library?).
> >
> > Does PyCash ignore the lock table in the database, then?
> >
> >
> > piecash is well aware of the lock table in the database but you can
tell him to ignore it if you open the book in read only mode via
> > book = piecash.open_book(book_url, readonly=True, open_if_lock=True)
> >
> >
> > To connect to the current session I think one would need to use the
Python connection in src/python or the Scheme interpreter. No external
process is going to be able to get at the running GnuCash instance's memory.
> >
> >
> > Looks complex and probably a) requires compilation and b) does not
allow to choose the python interpreter the user wants.
> > (as a side note, it is as an important security threat as having a
guile interpreter embedded or calling an external process ... the later
being less dangerous as he can only be dangerous through the HTML string it
returns)
>
> Sébastien,
>
> Heh, what about GnuCash *isn't* complex?
>

Still hoping *complexity* is not considered a feature ;-)

> It's the html string that I'm particularly worried about, because that
gets you to a well-known library with lots of well-known and
well-documented vulnerabilities [1] and it's well-known that we we use an
obsolete version. That's a very easy and tempting target.
>

Am I wrong or any guile report is already able to send explicitly  any html
string ? Isn't this vulnerability already there today ? The fact that the
html string is generated by guile in scheme or by guile after having called
an external process doesn't make a difference to me ... or I am missing the
elephant in the room ?

> I'm utterly agnostic about what format the report-config file is, but
since Guile already knows how to read XML [2] and the fewer dependencies
the better, I'd lean towards that.
>
Indeed, I had no success in using guile json but am no guile expert.

> Yes, having a Guile interpreter is also a security hole, though less well
known and with a much smaller attack surface than WebKit. I'll be very
happy indeed when it's no longer central to GnuCash.
As written, the vulnerabilities are both in guile (as it can execute any
command in your system) and in the report approach that will accept any
html string (and use a webkit vulnerability)

>
> Regards,
> John Ralls
>
> [1]
http://www.cvedetails.com/vulnerability-list/vendor_id-49/product_id-10007/cvssscoremin-5/cvssscoremax-5.99/Apple-Webkit.html
> [2]
https://www.gnu.org/software/guile/manual/html_node/Reading-and-Writing-XML.html
>
>