Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Secure IO in LaTeXML #606

Closed
dginev opened this issue May 8, 2015 · 7 comments
Assignees
Milestone

Comments

@dginev
Copy link
Collaborator

@dginev dginev commented May 8, 2015

This issue is a followup from the discussion on my failure to offer a temporary solution at dginev@0a6a1ec

Here is a small specification of what I'm trying to achieve:

  • Recognize "untrusted" (user-specified) from "trusted" (system) sources
  • Disallow any IO operations from any TeX input coming from an "untrusted" source
  • Only do so on demand, as we want to be "paranoid" for third-party TeX but "friendly" for classic LaTeXML use.

So far, we have scenarios where the untrusted sources are passed in as literal strings, or alternatively sandboxed ZIP archives, for which we know a sandbox directory.

A solution is then to connect:

  • The information whether the input is trusted with the tokens of that input
  • Consult that information in IO-enabling components, most notably FileMouth

There is a related refactoring need for the "REMOTE_REQUEST" global state value, which was a first "temporary" solution in this direction from a few years ago.

@dginev

This comment has been minimized.

Copy link
Collaborator Author

@dginev dginev commented May 8, 2015

Oh, you opened a duplicate #607 right after I opened #606. You can choose the one you like more and close the other, up to you.

@brucemiller

This comment has been minimized.

Copy link
Owner

@brucemiller brucemiller commented May 8, 2015

A reminder to implement some sort of restrictions on files that can be read (let alone written!) for server applications. This should basically only allow files to be read that sit underneath directories given in a whitelist. The whitelist would perhaps consist of @INC, whatever kpathsearch allows, and anything added by the ---paths option? .see some additional discussion in #605. I guess when processing a zip file in the server, the whitelist would include the path where the zip was unzipped. Command line invocation (assuming it even enforced the whitelist), would presumably explicitly include ".", but a server would not.

@dginev

This comment has been minimized.

Copy link
Collaborator Author

@dginev dginev commented May 8, 2015

Here is how my temporary workaround "evolved":
https://github.com/dginev/LaTeXML-Plugin-secureio

It was a bit annoying to setup, but it's there. If anything comes to mind that can be added to that "blacklist" for input macros, let me know. It's off-topic to this issue, but relevant if someone needs a temporary patch.

@dginev

This comment has been minimized.

Copy link
Collaborator Author

@dginev dginev commented May 8, 2015

Also, @brucemiller , whenever you have the feeling I am rushing a pull request without a strong enough reason for LaTeXML-core, please advise me to make a plugin, it's really the right solution for these cases.

@brucemiller

This comment has been minimized.

Copy link
Owner

@brucemiller brucemiller commented May 9, 2015

I'm thinking the above whitelist is probably safe & sane. Provided pathnames are properly canonicallized, it should be easy to test: just match that the path starts with one of the whitelist paths?
There was an issue (or maybe just in email) about canonicalization not dealing with symlinks correctly; can't find it now...

@dginev dginev added this to the LaTeXML-0.8.2 milestone May 12, 2015
@dginev dginev added the Authorea label May 25, 2015
@dginev dginev modified the milestones: LaTeXML-0.8.3, LaTeXML-0.8.2 Jul 17, 2015
@dginev

This comment has been minimized.

Copy link
Collaborator Author

@dginev dginev commented Sep 5, 2017

I still think this should eventually land in master, but am happy to stay with a plugin for now. Closing here.

@dginev dginev closed this Sep 5, 2017
@brucemiller

This comment has been minimized.

Copy link
Owner

@brucemiller brucemiller commented Sep 8, 2017

It seems ironic to use \usepackage{secureio} to disable other \input, but short of a better config system, I guess it works. It does restrict the user to a single .tex source file. I think a better solution in the long term is to whitelist the directories that can be read (and the searchpaths), but that's considerably more work to do reliably & efficiently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.