On 17/07/2017 15:18, Enrico Forestieri wrote:
I don't understand if the 'needauth' is new in LyX 2.3.0 or already existed.
This is new to 2.3.0 and is instead deemed a security improvement. Yes,
security is improved by allowing running dangerous converters.
I have to step in for a clarification:
1) without the needauth mechanism, LyX would run arbitrary R code snippets
embedded within a .lyx code whenever you tried to compile your doc, without
asking anything, without telling the user, etc...., such R code could even grab
your ~/.ssh/ folder and upload it to a remote site, or just rm -rf $HOME/
(delete your entire home folder)
2) needauth was added as a safety measure that tags those potentially dangerous
converters (the one executing R scripts) as 'needauth' (i.e., needs user's
authorization before being run), so that, whenever LyX tries to run that
converter, it will ask the user first
Therefore, it should be quite clear that needauth is a security improvement
(compared with LyX supporting R/sweave/knitr without needauth).
3) I liked to propose addition of support for running Gnuplot scripts as well,
with the corresponding converter tagged as a 'needauth' one
[ this last feature cannot be tagged as a security enhancement, but it's not
more dangerous than what we already had with R scripting ]
The text indicates to me that it's possible for a document to store some
kind of setting that allows a converter (here external program) to be run
in an automated manner without my manual intervention or consent.
it is possible to use preferences settings in THREE possible combinations:
A) forbid any use of any 'needauth' converters altogether (will be the default
for all users), that means users trying to compile a doc embedding a R script
would see a dialog telling them that it was not possible to convert that part
of the document because it is unsafe and the preferences options forbid it
\use_converter_needauth_forbidden true
B) allow for using 'needauth' converters in the normal/designed mode, i.e., only after
gaining user's authorization through a confirmation dialog that pops up on-demand
per-converter invocation and per-document (but it's not asked again once the converted
image is cached, so a second compilation of the same doc would NOT ask anything, because
LyX would use images from its cache in ~/.lyx/cache/*): users can check a "don't ask
me again for this document" if they trust the document, and there's quite a few
converters therein, so any further 'needauth' converter in the doc is run without further
auth question
\use_converter_needauth_forbidden false
\use_converter_needauth true
C) allow for using 'needauth' converters in the old unsafe way, as per status
quo before 'needauth' was merged in: any converter is just run, including
'needauth' ones, without asking anything; after commit [8a4fcd3d/lyxgit], when
a user tries to get to this configuration from the preferences, he/she gets an
additional SECURITY WARNING dialog explaining how unsafe/dangerous an action
they're doing -- at this point, if users go on and approve the config options
change, then they're assumed to know what they're doing
\use_converter_needauth_forbidden false
\use_converter_needauth false
There's an additional patch worked out in the TT below, which I like to think
of as the final solution:
D) execute any converter within a protected/safe sandbox, this can easily be
accomplished on Ubuntu/Linux using AppArmor, but it's not easy to merge such a
change unless there's a portable corss-OS way -- albeit, for Linux users, this
would be THE right way to go (with an initial transient until the AppArmor
rules are correctly tunes, which I cannot claim is a trivial task). This would
require no needauth, because the converter could be restricted to write only
within a temporary folder, and be forced into having no network access, then
only the created image file would be copied back from there, and anything else
trashed away.
I hope the above clarifies.
but
consider the following example:
I create a document with some embedded code to be run by converters. It's
my document, I trust it. Then I e-mail it to a colleague or perhaps my
customer for review. Time goes by and eventually I get the document back
from review, but the review took longer than expected and my next deadline
was yesterday, so I'm in a hurry and build "my" document.
this is an excellent scenario to add to the list of additional enhancements,
thanks; just TT-ified it:
http://www.lyx.org/trac/ticket/10735
The enhancement that was already discussed back long ago, was an expiry
timestamp
of the user's authorization, so that, when user says "don't ask me again", this
will be remembered only for X days, weeks, months, then it will expire, and if
the same doc is opened back 1y later, one would be warned again.
http://www.lyx.org/trac/ticket/10730
Another discussed one was about hashing the content about to be executed, so
that,
if it changed, then it's assumed to need authorization again; I'm not sure if
the
caching mechanism + needauth described above already has the same/similar
effect.
to the thread where this was all thoroughly discussed and what I described
can't happen...?
original trac #:
http://www.lyx.org/trac/ticket/10481
recent wiki page summarizing issues:
http://wiki.lyx.org/Devel/SafetyAndSecurity#sDevel.SafetyAndSecurity_11
Thanks,
T.
