Re: [lmi] Creating a chroot for cross-building lmi

[Vadim Zeitlin]

On Sat, 24 Sep 2016 13:20:48 +0000 Greg Chicares <address@hidden> wrote:

GC> 
https://help.ubuntu.com/community/BasicChroot#Accessing_graphical_applications_inside_the_chroot
GC> | You can run graphical applications within a chroot, but you need to
GC> | provide an X server for them to run in first. ... in the chroot shell type
GC> |   export DISPLAY=:0.0
GC> | And in the system shell type
GC> |   xhost +
GC> 
GC> [Actually, I used 'xhost +local:' instead, for security.]
GC> 
GC> However, now I think that's unnecessary--I just tried this:
GC> 
GC>   (host) $xhost -
GC>   access control enabled, only authorized clients can connect
GC> 
GC>   (guest schroot) $unset $DISPLAY
GC>   (guest schroot) $wine ./lmi_wx_shared.exe --ash_nazg --data_path=../data
GC> 
GC> and lmi's GUI worked. Am I missing something?

 As you already noticed, DISPLAY is, of course, necessary, but I'm not sure
why would you need to export it explicitly, normally it's already part of
the environment and should be inherited by chroot, as usual. Does schroot
prune the environment perhaps?

GC> Later, I decided to use the chroot as my normal user (with the same numeric
GC> uid). I've installed 'wine' only inside chroots. I guess this exposes me to
GC> an attack from msw malware that knows how to break out of a chroot using
GC> only the API that 'wine' presents,

 Again, it shouldn't be possible to break out of chroot. There used to be
bugs allowing this in various Unix systems back in the 80s but I don't
remember when did I hear about something as catastrophic as that for the
last time. It certainly was in the last millennium.

GC> But am I being naive?

 As always, the question is what is your threat model. I don't know the
answer, but I don't see any situation in which it would make sense to
attack your system via MSW chroot rather than in a more direct way.

 Regards,
VZ