Anyone using this yet? I would speculate, not many are using it. It needs step by step instructions. Otherwise, most users are lost at hello.
> Things debcheckroot does not check at the moment are the initrd and the MBR (master boot record). You may unpack the initrd by hand and check the files contained there against a sha256sum list generated by debcheckroot. The MBR can first be backuped by confinedrv/diskutils. Then reinstall it with Grub from a fresh boot CD and look if the boot sector has altered. Under normal circumstances Grub would install the exactly same code into the MBR. I guess "nobody" is going to do that. Sounds complicated. And I am saying that as a fairly technical user. (Maintaining Debian derivative distributions...) Users need very detailed step-by-step instructions. This is my experience from over 7 years of Whonix user support. Murphy's law. Anything can go wrong, will go wrong. Keep it simple stupid (KISS). Some stuff on usability: Quote To Toggle, or not to Toggle: The End of Torbutton https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton > mike, am i completely anonymized if i log onto my facebook account? im using firefox 3.6 with tor and no script on windows 7 machine. thank you. Quote https://www.bbc.com/news/technology-20445632 > In order to make sure the mobile phone frequencies are not being tracked, I would fill up a washbasin with water and put the lid of a rice cooker over my head while I made a phone call," said one interviewee, a 28-year-old man who left the country in November 2010. [tor-dev] First-time tails/tor user feedback https://lists.torproject.org/pipermail/tor-dev/2012-April/003472.html Eliminating Stop-Points in the Installation and Use ofAnonymity Systems: a Usability Evaluation of the Tor Browser Bundle https://petsymposium.org/2012/papers/hotpets12-1-usability.pdf I would also suggest a different design / additional feature. Rather than requiring a network connection or DVD, could you add a feature please similar to "apt-file" or "command-not-found"? What I mean by that: These tools download a cache while the system is running. debcheckroot could download/generate/prepare all the sha256 files on the disk. Yes, within the running system. Don't worry about verifying integrity of these files just yet. That will be answered later. Yes, these sha256 files could be maliciously altered. But that is something you can check later at debcheckroot runtime. Generating the (sha256) files required for later verification could be done using an apt or dpkg hook. Then, later when debcheckroot runs, it would rely on these files. But to check that these files haven't been altered, it could check them against repository signing keys. So debcheckroot would need a bit root of trust built-in or better configurable. For example, it could be sufficient to point debcheckroot at clean Debian repository signing keys. These would then be used to check the sha256 files. The advantage of this would be that debcheckroot can be run from Live USD or Live DVD. Offline. No need for a network connection since all files to be verified would already be prepared. debcheckroot could be a Debian package that gets installed in the running system. And then starts preparing the sha256 files for later verification. It could also run the verification within the running system. That would just be an integrity check and no rootkit hunt. Since a system that is already running could be infected with a rootkit already. (Similar to debsums.) The same debcheckroot package then could also be used started from a Live USD or Live DVD and then "just" change the root (local of what debcheckroot should check) from the boot medium to the internal hard drive. debcheckroot could then verify that the existing sha256 files on the disk have valid signatures and if so, start the verification of all individual files. To a rootkit hunter which laymen can use it's a long way to go. Some rhetorical question questions. How to I create a Live DVD / USB to check my running system? Download such a Live DVD / USB image somewhere? How do I mount the internal hard drive? Or mount an internal full disk encrypted disk? Then run debcheckroot on it? Could this be fully automated so these tests can be run routinely, easy? Graphical user interface? Run debcheckroot fully automated at boot (from read-only boot medium such as Live DVD), verify all files, then continue booting from the internal disk (kexec)? That would be similar to the verified boot feature which is already a default feature in iPhone, Android, and ChromeOS. Can we get iPhone and Android Level Security for Linux Desktop Distributions? https://www.whonix.org/wiki/Kicksecure#iPhone_and_Android_Level_Security_for_Linux_Desktop_Distributions Cheers, Patrick Elmar Stellnberger: > Dear readers of debian-security > > I have just released debcheckroot-v2.0: > https://www.elstel.org/debcheckroot/ > > The new tool can be used to check a Debian installation also against > previously unknown rootkits. It has many improvements towards > debcheckroot-v1.0: > > # usage of direct comparison or creation and usage of sha-256 lists > instead of the unsafe md5sums provided in the package header > # allow usage of multiple changeable media: i.e. DVD & BD-SL > verification rather than just BD-DL verification > # testing of symbolic links, of user, group and file-mode > # scanning the home directory for odd filenames that contain control > characters, on request: listing all hidden binary files in the home > directory > # download only mode + shuffling of download order for package download > via Tails/Tor and subsequent offline verification > # use of Python3 instead of Perl with built in support for tar, xzip, > gzip and bzip2; no more external helper programs required, works from > any live cd! > > Finally debcheckroot-v1.0 did no more work with current versions of > Debian as Debian now uses xzip instead of gzip. The new program supports > any of xzip, gzip and bz2 for compression of the data.tar.xz and the > controls .tar.xz inside the .deb ar-archive. Files are merely unpacked > in memory so debcheckroot keeps being quite efficient. > > I would be happy to discuss the new release here or to assist anyone who > wants to test the new tool! > > Regards, > Elmar >
