On 07/17/2017 06:30 AM, Enrico Forestieri wrote: > On Mon, Jul 17, 2017 at 07:03:09AM +0200, Guillaume MM wrote: > >> 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. > Please stop with this constructed arguments. This is simply mudding waters. > All these features entail the same security risks, so if one is serious > about security then they have to be removed at once. Not only that, among > all these features, the minted one is the most secure. It would have been > at the same level of risk of the others if one could activate it by a > mouse click. So, if something has to be removed, I would say it is the > more risky features. And the argument that they cannot be removed because > they are there since 2011 is simply hypocritical, given that one has to > be serious about security. I am really tired to see this kind of behavior > of using different criteria of judgment based on constructed arguments.
If I read JMarc's messages properly, then he also agrees that the security issues are essentially the same. That also seems right to me. It's true that we've always tried to be cautious about security. But there is only so much we can do. Warning the user that they are about to do something that is potentially dangerous, and making it as simple as possible for the user to manage those privileges, is the best we can do. I don't see the difference either between R-code and minted in this respect. So I'm inclined to go with some version of Enrico's patch. Richard
