Please excuse the throwaway account. I just want to anonymously report this issue:
After upgrading Whonix (/Kicksecure) from bullseye to bookworm with the release-upgrade script provided, the livecheck.sh script will allways detect that there is something mounted in read-write (and therefore show this in the systray). This is due to the weird fact, that since bookworm, lsblk -all shows empty loop devices from 0-7 that are all read-write and hence trigger livecheck.sh to believe the system is mounted in read-write.
I was not able to understand why these loop devices are present in bookworm.
This all occurs with the system correctly being mounted in read-only and started with grub-live, therefore confusing users.
@Patrick I made a pull request on the GitHub repo with a fix for the livecheck.sh issue. As of my testing, it should be compatible with all cases of lsblk output that I can think of. snapd, other loop devices in use, etc. It just removes the empty read-write loop devices with RegEx.
If there are still some issues, feel free to point them out or message me on GitHub and I will glady rework my solution!
Before trying to fix this, what are these loop devices when not using snap etc.?
lsblk_output=$(echo “${lsblk_output_unsanitized}” | grep -vPx ‘\S+\s+\d{1,3}:\d{1,3}\s+\d\s+0B\s+0\s+loop\s+’ | sed -r ‘s/^.+\s+([0-9]{1,3}:[0-9]{1,3})\s+([0-9])\s+([0-9]+.?\S{1,2})\s+//g’ | sed -r ‘s/(\s+[^0-9]+\s+\S*)$//g’)
This looks really complex. If this is the right and only solution at all, it should be split into at least 3 lines. This is to keep the ability to be able to debug this, to be able to see in the xtrace the contents after each step of string manipulation.
But before we need to know what these loop devices are so we can check if these can be ignored or not.
I was not able to find any information about why these loop devices are present in Debian bookworm / Linux 6. They are kind of “placeholders” and not actually active. If I, for example, mount a VeraCrypt Volume, loop0 which was 0B before now gets “claimed” and used for the volume (so its not empty anymore), only now actually being active.
I think it is not of any necessity for solving this issue to try to find an answer for why they are there. As long as they are 0B they simply to not matter and are of no concern.
As to your question if this is the right and only solution:
The only other solution I see is to omit the --all flag altogether, which I would strongly recommend against. The purpose of the livecheck.sh script is to warn the user if there is ANY disk (that is not an empty loop) that is read-writeable. To achieve this and prevent any possible exploits of the lsblk internal filtering if --all is not present (or if changes to lsblks filtering are made in the future; bugs) and really have ALL block devices in the list, we should keep --all. This is the safest way to do this and prevent against possible loopholes, bugs, etc, because we may not know the full extent of possibilities to omit devices when --all is not present. According to what Whonix and Kicksecure strive to be and are, I think my current solution is the one best fitting to their standards and goals.
Furthermore, RegEx is widely used in software development and is the industry standard for string manipulation. Therefore I see no issue with using it to filter out unnecessary list entries.
But you were right about the complexity. I looked a bit more in the lsblk command and found a better, much simpler and more efficient way of handling this by using the --output flag again with only the columns we need for filtering:
SIZE to determine if the device is empty
RO because this is needed after filtering to the real livecheck
TYPE to only remove empty loop devices
The RegEx got much more simple by doing this (since we don’t need to remove that much string overhead anymore) and I also added simplified explanations as well as split every single string operation into its own line, as per your request.
If not familiar with RegEx at all, I can recommend the website https://regex101.com/ for understanding and debugging the RegEx I wrote.
Select PCRE for this.
@Patrick I made a new commit with the improved and reworked solution.
If there are still some questions, issues or concerns please feel free to point them out and message me.
I hope this satisfies everything.
Yes, these are 0B loop devices but these are still read-write and not read-only. So as long we don’t really know their purpose, we don’t really know what we’re doing here. Just hiding a potential issue.
Thease are 0B at time of check as suggested by your pull request but there’s no guarantee that these stay 0B.
Asked just now:
And livecheck.sh currently doesn’t continuously re-check. Not sure it should. But when it detects a 0B read-write device being larger than 0B then the write action was already done and then what we attempted to protect from / inform about is already too late.
