On 14/11/2016 14:59, Stephan Witt wrote:
Probably we need some more tweaking to make a really good sandbox
(e.g. limit network access too?).

AppArmor does that as well, otherwise you can still make damages only reading 
(eg, read data from your home, pack it, send it / upload it somewhere); AFAIU, 
sandbox-exec is similar on Mac, just need to understand how to use those 
profiles, and/or whether it's worth writing a new profile for LyX.

It could be worthwhile to double-check whether it works, on what OS versions, 
what can be done with these profiles (guess one would sandbox-exec with various 
-f this, -f that, and change behavior?)

IMO, a prerequisite to make this technology useful for LyX is to
create child processes with only one code path. ATM we have many
ways to execute sub-commands for compiling TeX or convert images or
execute CAS commands or unzip files. I don’t know exactly how many
different ways to create a child process are used.

you nailed it down: the "profile" (the usr.bin.lyxwrap AppArmor config file) in 
my current patch:
1. catches a fairly wide set of external tools execution, namely: viewers for 
pdf (C-R), conversions for on-screen display (graphics/GraphicsConverter.cpp 
through the buildscript() machinery), conversions for PDF export et al. 
(src/Converter.cpp), I suspect it intercepts also CVS/SVN/GIT commands, and I'm 
probably forgetting something
2. due to 1., we need a fairly wide set of permissions, especially viewers, e.g., evince 
forced me into adding quite a lot of stuff about access to X11 session/tokens (but the 
standard X11 sub-profile on Ubuntu includes access to audio & video :-(...), dbus et al., 
similar if you want to preview HTML with Firefox, that would bring a ton of "perm 
dependencies", xdvi tries to access its own ~/.xdvi/whatever, emacs would try ~/.emacs 
and ~/.emacs.d/, image editors would have their own prefs et al., etc...., CVS et al. force 
you into keeping access to ~/.ssh (smth I really dislike) etc...

So, I'll try to clarify what a minimum of differentiation among these cases can 
be, and perhaps we can deal with 1-3 different profiles for these cases. 
Originally, I planned to protect *only* from conversion scripts and leave 
anything else untouched.

Another subtle case can be the one of having, e.g., a weird image name containing a 
'; rm -rf $HOME' or '"; rm -rf $HOME' or similar, that when expanded would 
end-up into a:

  "lyxwrap/sandbox-exec convert "source"; rm -rf $HOME source"; rm -rf 
$HOME.png"

where, as you can see, the wrapping might risk of becoming quite ineffective 
:-)!

Any (further) comment welcome, thanks!

        T.

Reply via email to