[Tex/LaTex] Is Arara safe/secure

araraSecurityshell-escape

I have just begun playing around with arara and I am curious if there are safety/security concerns. For example, pdflatex from TeX Live has shell escape disabled by default. If the TeX Live team think that shell escape is too dangerous (and I am not sure that is the reason it has been disabled) to be enabled by default, then I am not sure it is wise to give arara so much power. Is there a way to rein in the power of arara?

One concern I have is that it might be possible to inject a malicious arara directives into a package or the aux file.

I am not so concerned about shell escape, but rather other things that can be done. For example, can an untrusted package use the file contents environment to overwrite the pdflatex rule on the first pass such that on the second pass custom code is run?

Best Answer

I think my answer will be totally biased, but here it goes. :)

It's quite subjective for me to afirm that arara is safe or secure. It's just a program with a specific purpose, just like most of the tools available out there. Maybe the best answer I can come up with is: it depends.

arara per se simply expands directives into commands through rules that specify the way this expansion shoud happen. Commands are then delegated to the underlying operating system.

The program requires a valid directive (mapped to a rule) in order to run, otherwise the process stops.

Uh-oh, I could not find the 'foo' rule in the search path. Could
you take a look if the rule name is correct and if the rule is
accessible through the search path?

If there are no directives, arara will also complain.

I didn't find any directives in 'test.tex', and so didn't do
anything. Is that what you really wanted?

If we run arara with the --log option enabled, we can have a list of directives found in the .tex file.

21 Mar 2013 07:32:10.630 INFO  Arara - Welcome to arara!
21 Mar 2013 07:32:10.634 INFO  Arara - Processing file 'folheto.tex', please wait.
21 Mar 2013 07:32:10.635 INFO  DirectiveExtractor - Reading directives from folheto.tex.
21 Mar 2013 07:32:10.649 TRACE DirectiveExtractor - Directive found in line 1 with pdflatex.
21 Mar 2013 07:32:10.650 TRACE DirectiveExtractor - Directive found in line 2 with clean: { files: [ folheto.aux, folheto.log, folheto.sxc, folheto.synctex.gz ] }.
...

Heiko suggested a --dry-run option to arara, which consists of simulating the execution without actually running the commands. Hopefully it will be available in the upcoming version.

After getting the directives, arara will look for rules.

...
21 Mar 2013 07:32:10.799 INFO  TaskDeployer - Deploying tasks into commands.
21 Mar 2013 07:32:10.799 TRACE TaskDeployer - Task 'pdflatex' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
21 Mar 2013 07:32:11.010 TRACE TaskDeployer - Task 'clean' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
21 Mar 2013 07:32:11.083 TRACE TaskDeployer - Task 'clean' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
21 Mar 2013 07:32:11.099 TRACE TaskDeployer - Task 'clean' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
21 Mar 2013 07:32:11.104 TRACE TaskDeployer - Task 'clean' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
...

arara shows the full path for the rule according to the directive. Then the commands will be executed.

...
21 Mar 2013 07:32:11.108 INFO  CommandTrigger - Ready to run commands.
21 Mar 2013 07:32:11.108 INFO  CommandTrigger - Running 'PDFLaTeX'.
21 Mar 2013 07:32:11.108 TRACE CommandTrigger - Command: pdflatex "folheto.tex"
...

Back to the question. Is it possible to run malicious code through arara? Yes. Is this a problem? No. :) After all, we can get, say, a Perl program and deliberately inject code into its execution. Or write a .tex file with malicious Lua code inside it. Or have a naughty Makefile that runs rm -rf / in our system.

I think the security issues are valid. Let's see an example, the clean rule.

!config
# Clean rule for arara
# author: Paulo Cereda
# requires arara 3.0+
identifier: clean
name: CleaningTool
command: <arara> @{remove}
arguments:
- identifier: remove
  default: <arara> @{isFalse(file == getOriginalFile(), isWindows("cmd /c del", "rm -f").concat(' "').concat(file).concat('"'))}

Using this directive

% arara: clean: { files: [ foo.aux, foo.log ] }

will make arara remove two files, foo.aux and foo.log. There's an important check which prevents arara from removing the main .tex file if no files directive argument is provided. Say,

% arara: clean

does nothing.

Let's say we will replace the default instruction by

default: <arara> @{isWindows("cmd /c del", "rm -f").concat(' "').concat(file).concat('"')}

If we try

% arara: clean

the main .tex file (possibly foo.tex) will be gone! Neat isn't it? :)

Of course, we are talking about a faulty rule.

arara has the following workflow:

  1. Read all directives.
  2. Find their corresponding rules.
  3. Expand directives into commands.
  4. Run all commands.

That's the basic idea behind the program.

It might be worth mentioning that the program makes use of a library to execute these external commands which doesn't allow subshell calls.

Anyway, I really don't know what else to say. :) We are all vulnerable to malicious packages, but that's a risk we need to take. Thankfully, source code has to be available in order to hit CTAN (not entirely true, but true for packages), so we can always check entries for suspicious elements.

As I said, LuaTeX for example allows I/O from Lua, which can also be dangerous. We are exposed to some level of threat at some time, it depends our use. :)

And running arara (or any program) in a server without a sandbox... ouch. :)

Related Question