Specifically, I am interested in the safety of using (for example) xprop on random qube windows. There is no command that I can find to list all the windows belonging to a specific qube. It seems that I can do it with a bit of xprop to find the ids and a bit more to find the names. I even found that @alimirjamalimentions it here, although I did not find more. The gui docs seem to indicate that such data must be well sanitised.
Is it a reasonable thing to process those strings ?
Can anyone point to other bear-traps we should be wary of ?
Thanks for any pointers - especially if I’ve missed an enormous thread about it!
I would treat xprop output as untrusted text. Reading window properties is much less scary than mounting or parsing a foreign disk image in dom0, but the strings can still be controlled by the app/qube and can contain odd characters. So it is reasonable if the script only compares/prints them and always quotes variables; it is not reasonable if it feeds them into eval, a shell command line, filenames, or regexes without escaping.
The bigger bear traps are tools that parse complex untrusted formats in dom0: mount/fsck/fdisk on foreign images, archive tools, image/PDF viewers, and anything that opens files copied from a qube. For this kind of window inventory I would keep the dom0 part tiny: collect ids, map them to a qube name, output plain text, and do any heavier parsing in a disposable qube.
Yes - it is always a timely reminder. Also, of course, any files, device, and disk volume content. Thank you.
After looking into the gui code (sanitize_string_from_vm() function), I am feeling that the strings are only assured to be:
printable and
either ascii, or possibly unicode
but can contain shell code, etc.
I was already considering that they are:
not suitable for any kind of handling in any casual shell script - too easy to miss a pair of quotes.
best done in python, or similar.
not likely to subvert the actual xprop executable.
You confirm my feelings, I think.
My xprop interest is exactly what you suggest: a list of ( id, vmname, safe window title ), mostly because I have not taken time to look at -and trust- the often recommended “devilspie”.
In honesty, I am even considering that we must take care with the content of the executables and other files in dom0 ( after being reminded of the GNU ‘strings’ ability to process input with the many-CVE-winning bfd library).
I am wondering where there are other smaller but well-hidden traps, also!
I think I shall pursue this only with some major sanitising of those strings. As @unman says, a lot can be done with only qube name and window id.
Searching for window titles could maybe be done inside each qube, but I did not find a way to access them in quick tests. Maybe i missed something.
Shellcheck is good, but only correct script handling of possibly-malicious data is not enough for me, if there will be any output of it, because it just moves the risk downstream to whatever I might do with the output.
Possibly I will start with an unfriendly whitelist filter to ascii-alphanumeric plus space and prefix with a known non-executable string.
Will be using python to eliminate invalid utf8 - which seems able to pass the filtering in the guid (not tested, just a quick eyeball).
Blacklisting characters that might be able to influence shell control flow seems like too big a job for my purposes and brain power… and unreliable considering bash(?)
So titles will be horribly mangled, except for anglophone windows.