What analysis of Texlive's restricted permissions model exists?

Question

TH. writes, in How should one use \write18 with BibTeX:

Background
Now that TeX Live 2010 has a restricted \write18, I figured it'd be reasonable to update my cv which uses the bibunits package to run BibTeX for each of the .aux files.

I'm aware of a history of discussion about using limited priorities to sandbox Tex execution, but I hadn't seen anything saying that the difficulties doing this had been solved. Is there anything like a report, ideally something along the lines of a security audit, that gives a threat model and discussion of Texlive's ability to deal with it?

Postscript

Just to be clear, this question is about understanding what risks the use of Texlive 2010 places its users at.

The main thing I'm worried about —but the question is not limited to this— is a risk comprehension issue: it's easy to grasp that with '\write18' accessing the full privilege user shell, you are letting your Tex manuscript to do anything to your machine that you can do (hopefully, that is, without admin privileges). With restricted shell, the risk is more subtle: the restricted shell can only run permitted executables, which sounds safe, but a cleverly constructed Tex style file might be able to exploit a bug a "safe" executable so your machine joins the Storm botnet. The value of a security review is that it makes the risk clear, and anything like one is a good thing.

Answer 1

I first started commenting on Will's and Joseph's comments and answers, but my reply may be too long for a comment. So, first of all, concerning the withdrawal of restricted \write18 in TL2009, if I remember correctly there was mainly three reasons:

1. There was specific issues on Windows, mainly related to the fact that Windows picks binaries from the current directory first (even if . is not in the PATH variable). Combined with TeX ability to write arbitrary files in the current directory, this was a huge threat. The approach taken now is (a) forbid writing files with "executable extensions": exe, com, etc. (taken from the standard environment variable PATHEXT if set at runtime, or from a built-in list otherwise); (b) invoke executables with full path whenever possible.

2. As you rightly point out, the system is as weak as the weakest allowed executable. There's two things we want from an allowed executable: (a) don't allow execution of arbitrary commands and (b) respect TeX file I/O restrictions as implemented in TeX Live. Many executables in the initial default list (most notably bibtex and makeindex) didn't satisfy (b), now they do. More importantly, the script epstopdf (which was the primary motivation for restricted write18) didn't, and at some point was prone to shell injection (hence arbitrary command execution). Now we believe epstopdf is robust in this respect (more precisely, its newly-created restricted version repstopdf is).

3. A implementation mistake (more a typo than a design issue btw) was discovered lately on Unix, which allowed shell injection directly from TeX. While we could have fixed it immediately (hence delaying the release further for rebuild), at this point we really felt like the feature was not ready for prime-time and required more relaxed (as opposed to rushing for release) thinking and careful proofreading.

To sum up, the current approach is not new, it's basically the same as planned for 2009, only a lot of "details" have been fixed, but the devil is in the details. Beside the "historic" interest, I hope this explanation sheds some light on which issues were considered.

Now, security is not only about executing commands, it's also about file I/O. The "texhack" paper cited by Joseph deals only with writing or reading files, which is nothing new (but not completely unrelated to restricted \write18 either, see points 1 & 2b above). Basically, file reading may lead to information leak in some contexts (tex as a web service), while file writing may lead to data loss or arbitrary command execution. As pointed out in the paper, TeX Live provides some protection. By default, only file output is restricted to the current directory or TEXMFOUTPUT if set, (and writing dot-files on Unix and files with "executable extensions" on Windows are forbidden), but file input can easily be restricted in the same way. It is very important to notice that this protection is efficient only if you process untrusted files in a "safe" directory (a temporary one for each document), as opposed to your home.

Concerning documentation, a section was added in the TeX Live guide (section 1.4). It doesn't discuss the subject extensively, but at least sums up the mains issues and the precautions a user can take.

Answer 2

Just for a little history: restricted shell escape has existed since TeX Live 2009. It was decided to be inactive by default then due to security concerns.

If memory serves, here's where the problems started being discussed before the feature was dropped from being "on by default" in TeX Live 2009: http://tug.org/mailman/htdig/tex-live/2009-July/021574.html

And here's the end of a (rather long) thread in which, eventually, the feature was announced as withdrawn: http://tug.org/mailman/htdig/tex-live/2009-October/023430.html Few details were given on the exact decisions made leading up to this.

But I don't follow the TeX Live mailing list most of the time so I'm not sure if or when the new-and-improved implementation (active by default) was discussed there for TeX Live 2010.

Answer 3

I know this isn't an answer to the question, but perhaps could help you with your problem. PerlTeX allows you to embed Perl code as a LaTeX function. When compiling if you use perltex --nosafe myfile.tex then the perl process has free reign to call system functions. I'm not sure if this could help your problem (because of an order of operations, though if \write18 would work at compile time then this should), but it is a way to get full access to your system as well as other benefits of using inline Perl code in your source.