Hi, alright, I see.
There is one (not security critical) odd thing regarding these wrappers. Why do you check names/paths for output and input regarding kpse when wrapping mkdir? [1] Checking if it's a valid output totally makes sense, but why also check if it's a valid output? (sorry for bothering again, but since this is security related, I don't want to silently ignore this here) I see according to git blame this was changed ~1 year ago when adding the wrapper but maybe someone still knows the rational behind this. Also to be clear, I'm not seeking to remove the additional check in luatex, I just want to understand (and react based on it for the custom wrapper I'm writing). With kind regards Lukas [1]: https://gitlab.lisn.upsaclay.fr/texlive/luatex/-/blob/fb02a155b41f461327899811835f78ba52f41c28/source/texk/web2c/luatexdir/lua/luatex-core.lua#L269 On Tuesday, January 21st, 2025 at 22:36, Hans Hagen <j.ha...@xs4all.nl> wrote: > > > On 1/21/2025 10:03 PM, Lukas Heindl via luatex wrote: > > > Hi, > > > > sorry to bother you again. I have another request probably also into the > > direction of libraries. In order to make the script work with all engines, > > we need to execute the script (instead of loading it with require() as this > > would only work in lualatex). As a result, the script will be totally > > unrestricted and none of the security wrappers that would be in place with > > shell-restricted enabled are available. The issue is we do still want to > > make the script be secure (actually we want it to be in the list of > > commands allowed with shell-restricted in the end). > > For this we already wrap security sensitive functions like io.lines to put > > the security guards of shell-restricted back in place. But here it is easy > > to miss some checks and also it weakens security in general if we need to > > implement these security wrappers over and over again (maybe this can be > > compared to "never roll your own crypto"). Also in the future we might find > > a bug / vulnerability in the security wrapper and it would be not only > > laborious but also prone to errors (keeping attack vectors open) having to > > apply the patch to all utilities shipping their own security wrappers. > > > > So you might already guessed what I'm asking for: Can we somehow make the > > wrappers that are defined in luatex anyhow (and it wouldn't make much sense > > to implement them anywhere else) available to texlua scripts? Precisely, > > I'm speaking of the functions defined / assigned here 1. > > > > You'd probably just need to move these functions to a security/io library > > and refer to it at the place where you currently define these wrappers. Oh > > and of course the table reflecting this library probably should be > > read-only in order to avoid the user tampering (deleting or even worse > > modifying) these wrappers. But this can be done in lua e.g. like it is > > documented in PIL 2 (I know this is the old 5.0 version, but the snippet > > still works reliably). > > You could of course still make copies of the functions for the > > luatex-core.lua file, but having the library read-only probably also makes > > sense in this regard. > > > > I see you probably want to keep luatex small in order to make it easier to > > maintain and move as much as possible (like the pathutil in my previous > > request) to external lua libraries. But in this case any duplication of > > this code makes it more likely someone forgets to patch it or makes a > > mistake in implementing it correctly. > > > > If you consider implementing this and I can help somehow, just let me know. > > > > With kind regards > > Lukas > > > As Luigi already mentioned, one can do a lot in lua so that's where the > work has to be done and we have no plans for extensions like these. As > luatex is rather stable it is unlikely that something file / execute etc > related will be added or change. Messing and opening up the security > related helpers only can make things worse. > > Also keep in mind that using external libraries in itself is a security > risk. And tex users should know what they're doing / running as there > are ways tex and friends can mess up your system anyway. > > Hans > > > ----------------------------------------------------------------- > Hans Hagen | PRAGMA ADE > Ridderstraat 27 | 8061 GH Hasselt | The Netherlands > tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl > -----------------------------------------------------------------
