On Mon, Jul 17, 2017 at 02:10:44AM +0200, Christian Ridderström wrote:
> 
> Regarding, Minted, which is an alternative to insert pretty program
> listings in your document.
> 
> At the moment it takes manual (typing) work to cause security issues in
> connection with minted.
> The "at the moment", likely refer to e.g. LyX 2.2.2 as [1] gives a nice
> illustration with screenshots on how to add the option '-shell-escape' to
> the converter 'pdflatex'.

No, "at the moment" also refers to 2.3.0 where the only difference with
respect to [1] would be that you don't have to use ERT and manually add
the minted package.

> The downside with adding this option is that now
> other LaTeX code in the document has the possibility of doing "bad" stuff
> to my system.

Yes, and this is in no way different than using a dangerous converter,
which might be doing "bad" stuff to your system.

> Further, my LyX is now configured with this -shell-escpae that will then be
> active for all other LyX documents that I build. Oops.

Yes, and this was the motivation that lead to the proposal of several
alternatives. I think the most effective was the one that allowed to
add -shell-escape to selected documents with the possibility of revoking
this permission. There was an icon indicating this fact and clicking it
one could revoke those rights.

This was a reasonable alternative, IMO, not specifically tied to minted,
but it was not agreed upon by everyone.

> Note: I'd probably deal with the security issue here by using two
> separately configured LyX instances that use different '-userdir':s.
> It would be nice with a strong visual warning that I'm using the "unsafe"
> LyX though, but i guess I could manually configure a different paper colour
> in LyX.

I think that it would suffice configuring two different converters rather
than using different user dirs.

> If I've understood the proposed patches correctly, they involve making it
> easier for the user to enable -shell-escape, and also easier to disable
> shell-escape.  I'm torn here. Some of the proposed UI-approaches weren't
> bad, but I'd probably still worry that we're making it to easy for the user
> to do dangerous things.

As you have discovered, people need to set -shell-escape for their purposes,
and it may happen that this setting remains there completely unnoticed in the
future. I think that making it easier enabling and disabling -shell-escape
simply increases security. In one of the patches I posted you could see an
icon that was indicating that that particular document would run with
increased privileges, and you were able to revoke it.

> For Minted I'd then prefer to keep the old behaviour for now and add better
> integration when/if minted doesn't need shell-escape.

So, there would be nothing to do, as the only difference with the old
behaviour would be not using ERT.

> As for the other dangerous features, presumably related to something called
> "needauth", I don't know anything...
> I googled and found this [2]:
> 
> ----
> The converters definition syntax (LYX_HOME/lyxrc*) now supports a new
> option, 'needauth', to prevent completely automated execution of the
> converter, unless LyX acquired explicit consent by the user. This is a new
> security feature, useful for converters that are capable of executing
> arbitrary code, such as R scripts (used with sweave/knitr), embedded within
> LyX documents. The user needs to explicitly grant per-document permission
> on the first need for using the converter on each document, unless he/she
> checks the "Don't ask again for this document" checkbox in the permission
> dialog. The new behavior can be fine-tuned from two new options in the
> preferences dialog (see their description below). These also allow for
> disabling 'needauth' converters altogether, if desired (default behavior).
> ----
> 
> 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.

> However, and here I'm probably offending people and stepping on mines in a
> single paragraph. This seems bad to me.
> 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.
> Supposedly I first had to check "Don't ask again for this document" 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.   Oops, some of
> the embedded code is now malicious, but the document still contains my
> setting that lets the converters execute... So apologies for not knowing
> the details here, but if this is being introduced in LyX 2.3.0 it sounds
> like it could be pretty bad and I think the security aspects should be
> discussed.  {KABOOM} is hopefully the sound effect when someone points me
> to the thread where this was all thoroughly discussed and what I described
> can't happen...?

All of what you say is reasonable. I think that it is also reasonable
looking at this in the following way. We all agree that going out of
home is risky and, for security reasons, it would be better not to do
that. But, of course, you cannot always stay home and have to take some
risk. I think that people needing -shell-escape will simply add this
option and forget about it. Yes, they will be at risk, but they accept
it. If we support -shell-escape, we could detect this and nag the user
that his converter is potentially dangerous, suggesting to use the
support LyX gives for -shell-escape. In this way, the user can add the
option only for the documents actually needing it, and he has a visual
feedback of the potential risk.

I don't understand why this is not acceptable.

-- 
Enrico

Reply via email to