Le 17/07/2017 à 00:49, Christian Ridderström a écrit :
On 5 July 2017 at 06:59, Scott Kostyshak <skost...@lyx.org
<mailto:skost...@lyx.org>> wrote:
Dear all,
This is an important topic since it involves security. I'd appreciate it
if you spent some time on understanding the issue.
I see three options for what to do about the minted + shell-escape
issue:
1. Revert the recently added minted support.
2. Keep the current state of master.
3. Apply the patch at [1] (also attached for convenience).
Hi Scott,
I think you're doing an excellent job as release manager and also when
summarising the issue. I therefore have to apologise that even though I
have read various postings/threads on this topic, I'm still confused.
Perhaps I can expand on that:
- What do we lose by doing 1) above?
- Is 1) necessary for users in order to use minted, or is it a
convenience feature?
- How many users do we think need / want to use minted, i.e. how many
users are affected?
Opinions seem to vary regarding what's secure and I cannot say anything
to that. My general inclination is to prefer that the user to go through
a bunch of manual steps in order to use dangerous features. If they
remain in place, so be it. But perhaps we could warn the user when he's
configured converters to use shell-escape, or if LyX was started with
some global option enabling shell-escape. Perhaps by making the LyX
window "look dangerous" like private browser windows, or more
realistically flash a warning before each build.
As an aside, I've used org-mode documents in Emacs to invoke MATLAB on
snippets from within the document and it's very nice, except the really
annoying part where you for each snippet have to approve that it's run.
Each time. A big bug in org-mode is that it's not properly showing the
snippet that's about to be executed before you approve it to be run...
Perhaps I'm a masochist...
Hi Christian,
The current needauth interface is not so much better in this respect. It
only shows the unsafe command line about to be run. Various degrees of
compromise between security and usability are proposed: always allow
needauth / always for this document / allow once / never allow. The
default is never allow, and after going to the preferences, the user is
suggested to always be asked.
Various UI improvements that you and others have suggested are subsumed
by some articles I have sent to the list. I am convinced that if one
thinks enough about it, one can get to a better secure UI. This is
to me the best hope to get to a more reasonable balance between security
and usability in the future, because the AppArmor stuff will be harder
to put into place.
Enrico argued that there are other (equally) dangerous converters
already in LyX. Then that's something to address. Does it have to be for
this release?
In 2.2 and before, a document could contain R code which could cause
arbitrary code execution with user privilege during compilation. The
user was not warned that a document could contain such code. (R needed
to be installed, though.)
I think I did not really measure the extent of the problem before
Tommaso's work to patch things up. This is because LyX has always been
quite strict with security, refusing for instance to directly open links
from documents (although a secure implementation of this would be quite
simple: one would just need a confirmation dialog with the URL clearly
displayed).
Starting with 2.3, Tommaso's needauth feature asks for a confirmation
before running converters labelled as needauth, and R code is now
labelled as such. Users not expecting to see R code are now safe, but
ones who expect to run R code are still unsafe. According to Tommaso,
this was meant as a quick measure before a more elaborate containment is
in place (e.g. using AppArmor in Linux–this seems experimental for now
and it will be difficult to integrate it since a proper solution
requires one for each platform).
Support for gnuplot has been rejected for a long time because of
security, but now taking advantage of needauth it has been introduced.
There are specific issues with gnuplot being also run for previews.
There is currently a separate discussion about gnuplot.
Then there is the new minted implementation. The issue with minted is
that it cannot compile without -shell-escape. There seemed to be an
agreement that this would encourage users to configure -shell-escape in
whatever ways, and that this seemed bad enough to fast-track (between
feature-freeze and beta release) the inclusion of a needauth-like
interface for -shell-escape. Now it seems that there is no
longer an agreement that there is an issue at all and that the current
partial support of minted that fails to compile on the default
configuration is acceptable. The issue, IMO, is that proposing something
in the interface is both an encouragement to use (including for users
who would not have cared or known until then) and a promise that it is
and will remain supported.
The main difference between minted and other uses of needauth(-like)
interfaces is that in this case the sole reason for compromising between
security and usability is for running Pygments from inside LaTeX when in
principle it is similar to e.g. running bibtex. The actual feature is
Pygments, and minted.sty is only an interface to it, tailored to the
needs of LaTeX users rather than LyX users. In other uses of
needauth, there is no way around making a compromise between
security and usability (this would be different if R and gnuplot
proposed safe modes).
I have asked if there were other reasons to implement a needauth-like
interface for -shell-escape and I have not got any other use case AFAIR
(I wonder if the thing to cache tikz drawings could be one).
If that's something to discuss, I can't say. Are many
users currently exposed, i.e. likely to be using it?
Dangerous converters are installed for all users, and currently bad
things can happen (only) for people relying on these dangerous
converters. (Assuming the user who does not expect to have to run one
does not allow it.)
It's bad if we
have security holes, but it's not necessarily good to immediately yank
something out. On the plus side, you as the release manager can decide
what's needed here as far as I am concerned.
I'm sorry for not being of more help, but hopefully my comments will
trigger someone else to contribute something more helpful.
/Christian
Thanks for your input.
Guillaume
