taskManeage - Tasks: task #15694, pdflatex: why allow write18 with...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #15694: pdflatex: why allow write18 with -shell-escape?

Submitter:  Boud Roukema <boud>
Submitted:  Sun 14 Jun 2020 03:56:13 PM UTC
   
 
Should Start On:  Sun 14 Jun 2020 12:00:00 AM UTC Should be Finished on:  Sun 14 Jun 2020 12:00:00 AM UTC
Category:  Analysis Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  boud Percent Complete:  100%
Open/Closed:  Closed Effort:  0.00

Wed 17 Jun 2020 02:47:50 PM UTC, comment #4: 

Thanks for implementing the commit and splitting off the wider issue into a long-term task. I'll add a comment over at that task.

Boud Roukema <boud>
Group Member
Wed 17 Jun 2020 02:44:14 AM UTC, comment #3: 

Thanks a lot Boud, it is now pushed into the Maneage branch as Commit 1a4066d08622.

As explained in the edited commit message, this is primarily an issue when someone only runs a LaTeX command and doesn't expect it to silently call any other command. Something like arXiv's servers for example.

But in the context of Maneage (which is actually a software, running many silent commands on the host long before it reaches 'pdflatex'), a malicious project-creator can embed their malicious code anywhere in the project, before control comes to 'pdflatex'.

The user should indeed take security seriously and if they don't trust the Maneage-derived project, they should run it in a container, or better yet, an isolated virtual machine. In fact tha t is why I am now working on a Dockerfile for "Maneaged" projects. People would be much more comfortable running so many commands in an environment that doesn't contain their email credentials or SSH keys for example!

Fortunately Maneage doesn't require root access, so a Malicious project creator can't permanently disable the whole system. But as mentioned above for passwords and SSH keys, there are still many user-specific things that a malicious project author can exploit. So generally, from the security point of view, as with any software (that you shouldn't blindly trust), it is best to run a random "Maneaged" project with proper security conditions in mind.

But anyway, the comment above 'pdflatex' is kept to let people know about the situation generally ;-). Thanks for highlighting this important point ;-).

I am now closing this issue, but just opened task #15696 to continue the general security discussion there and hopefully add a good and clear warning at the start of Maneage's configuration step.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Mon 15 Jun 2020 11:02:02 PM UTC, comment #2: 

I haven't yet had time to trying using PGFPlots. I'm not proposing
that we exclude it, but we do need to warn the user. A debate
about whether the security risk is worth it or not can be started
later, by people who know enough or who are sufficiently interested,
but it would be unreasonable to expect the user to "trust us"
and override a security recommendation without any justification
or information on where to develop the discussion.

Here is a proposed fix:

https://codeberg.org/boud/maneage_dev/src/branch/shell-escape-security-warning

https://codeberg.org/boud/maneage_dev/commit/c69bde3ca5ee39c81beb655af8f4c1d4c8f0ab52

Without a warning like this, I see the issue as still open.

Boud Roukema <boud>
Group Member
Sun 14 Jun 2020 07:27:25 PM UTC, comment #1: 

This is needed by PGFPlots when it wants create figures as separate separate PDFs. You can see two such figures in the default Maneage branch in 'tex/tikz' directory.

Of course, if someone doesn't use PGFPlots, they can remove this option manually. But since the default branch currently uses this feature, before moving it we have to see if we should remove it from the default branch.

I personally think that promoting PGFPlots as a visualization tool is a good thing for reproducibility and avoiding complexity because 1) it build plots within LaTeX (not needing any special dependencies, unlike Matplotlib for example!) 2) Because the raw data/table has to be given to PGFPlots to draw the plot at the same time it builds the final PDF, it encourages people to keep the actual data before making the plots.

But of course, if someone wants to use another plotting system they can just build the plot before building the paper, and give the plot's PDF to LaTeX. Its up to them and we don't force it.

However, for those that are just starting, or don't have any special preference, I think that encouraging them to use PGFPlots   (implemented in the demo) is a good step forward for encouraging more robust and reliable tools, even when they aren't using Maneage.

What do you think? If you agree, please close the issue ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sun 14 Jun 2020 03:56:13 PM UTC, original submission:  

In reproduce/analysis/make/paper.mk, we have


    103           pdflatex -shell-escape -halt-on-error $$p/paper.tex


but the info pdflatex page says

>        -shell-escape
>              Enable the \write18{command} construct.  The command can be any shell command.  This construct is normally disallowed for security reasons.


Why should this security concern be overridden?

Boud Roukema <boud>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by makhlaghi (Posted a comment)
  • -email is unavailable- added by boud (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-06-17 makhlaghi CategoryNone Analysis
        StatusNone Done
        Assigned toNone boud
        Open/ClosedOpen Closed
    2020-06-15 boud Open/ClosedClosed Open
    2020-06-14 makhlaghi Percent Complete0% 100%
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code