Main device was never 24/7. I checked the logs on the router that showed me the ssh logins over months. That too wasn’t always on. But the logs show me what it was doing when it is on. However I’ve never myself logged in to my router until I noticed strange upload quantity by way of another metric system. Thats when I saw some other ssh that definitely was not me.
The building has poor network security but good physical security. I have access to the buildings cameras. I also have hidden cameras as a backup. No one touched my box. I also have TPM setup. My bios hasn’t been tampered with. I bought the motherboard cash during travels. @fsflover No interdiction. Yes I use coreboot. My only concern is network.
Can we get back on topic? I simply want to learn how to audit a qubes install. I’m sure I can’t be the only one curious about this. The solution to audit cannot always be “throw away computer and just reinstall from source” can it? Maybe I’m wrong. But I think it’s would be a good skill to have to be able to audit one’s system. I just personally don’t know which way to go about it. But I’m willing to learn! If some nice person can offer guide. Thanks u.
If you do not trust the software running on your device, you cannot trust what it says to you during a “verification”. So I don’t see any reliable way to check that. Try this instead:
1 Like
I asked Joanna about this a long time ago on one of the Qubes mailing lists. I can’t find the thread right now, but you can probably find it with enough searching. I’ll try to summarize the conclusion, but my memory is pretty terrible, so I apologize in advance for getting anything wrong.
Based on what I can recall, the upshot was basically that there’s no way to be certain that a computer has not been compromised and that this is true of most computers in general, not just those running Qubes. Basically, the idea is that no matter how thorough of an audit you perform, there can always be something malicious that you failed to detect and that this is a practical concern, not just a theoretical one. Therefore, any “OS audit guide” can at best say: Here are some things to check. If you don’t find anything, then the computer might be fine, but it might not be. There might be something you missed. There’s no way to be certain. (Such certainty might be possible with a formally-verified system, but Qubes is not such a system.)
This is part of the reason we don’t have any such “audit guide” for Qubes OS. We don’t want to deceive or mislead or users by offering security guarantees that we know are unachievable. We strive to do the opposite: To be frank and transparent about our security limitations. The other reason (probably the main reason) we don’t have such an “audit guide” is that it would be extremely time-consuming to create and maintain, and not just anyone can do it. For example, I wouldn’t be able to write it, because I lack the expertise to do so. It would have to be our best security folks, and they’re always busy with more important things, like building and maintaining Qubes OS itself.
However, none of this prevents the community from writing its own guide.
7 Likes
Thank you for your in depth answer on the matter.
I’ll move ahead with reinstalling. And redo whonix and such.
Could you link me to the mailing list?
Also if I wanted to figure out and start studying all the working parts of qubes and start picking it apart file by file, how exactly would I do that? Is there like a map of the OS and all it’s parts? Or how could I go about mapping it myself?
I’m guessing the best place to start is from boot to gui login. I’m just not sure how I can produce a print out or log reading that would show me every thing loaded, including all dependencies.
Thanks for any tips
Are you sure your not looking at the traffic caused by tor (as part of whonix)?
We actually have several mailing lists, which are all explained here, with links to various web interfaces for searching the archives:
The aforementioned conversation probably would have been on either qubes-users or qubes-devel.
I’d suggest having a look at the “System” section of the developer documentation:
1 Like
Thanks.
I’ll do the paranoid backup. Is my understanding correct on the process? I do a regular qubes backup using the qubes os backup utility which if I remember correctly makes an encrypted .bin. Then on the fresh qubes install instead of gui qubes backup restore, use dom 0 with the following command,
qvm-backup-restore --paranoid-mode --ignore-missing -d sys-usb /media/disk/backup.bin
Thanks everyone for all the help.
Tried doing in dom0
qvm-backup-restore --paranoid-mode
And --plan-b
Returns qvm-backup-restore: error: unrecognized arguments: --paranoid-mode
Anyone know why?
Yes, and re-appeared in R4.1 (done properly now, using DispVM to do all the complex processing).
2 Likes
@marmarek @adw little new to all this. Unless you think I’m going to run into a million other problems I’d like to give this a try. I found r4.1 GitHub - QubesOS/qubes-release-configs could you give some guidance on make? I only did this once before for something else. Basically I downloaded the folder from github, then ran make then a file name or something like that. But never did this with qubes, so I’m not sure of the exact process. I’d need to create burnable file for usb stick install. Or that’s what I’m accustomed to. Thank you.
Testing is intended for advanced users only. Given that you say you’re new to all this, I would recommend sticking with the stable release. However, if you wish to read more, see:
and
1 Like
Ah the build system, that’s what I was looking for. Thank you.
What do you think about this work around to access the paranoid mode. Setup r4.1 on a temporary drive just for the purpose of using paranoid mode to import and hopefully clean those templates of concern, then backing them up again, then importing them back to a clean install of 4.0.4 system so I don’t run into stability issues that I don’t have the skills to troubleshoot.
1 Like
I spent a few hours on those docs preparing to build this .iso. Then I found this: Signed Q4.1 alpha iso
Is there any way to update the docs myself to simply state “if you want to downloaded a signed rc .iso, here’s the ftp page”.
If the RC iso are signed and I just want for general testing, I’m not sure the benefit of spending all that time building myself. Obviously it would give me greater experience. But I have a --paranoid backup and android-x86 compatibility problem and need a quick solution and could put the additional experience gaining on hold. 
Instructions for submitting doc changes are here:
It is not entirely clear to me whether this change would be a good idea, however. For one thing, an alpha and an RC are completely different (almost opposites on the pre-release spectrum). For another, users should probably not go to the FTP page expecting there always to be an up-to-date alpha ISO there. Most likely, there would be some kind of post or announcement when one is available (like the one you linked), which then obviates the need for separate documentation.
1 Like
Whoops. Missed this. We could have saved you those hours. 
You also have weekly signed ISO. But after the updates they should be pretty much the same. Just FYI: QubesOS 4.1 Signed Weekly Builds
Plus, a beta is now available:
Tried the beta last day. Didn’t install. I tired all the install options. Same. Says error halting install, check logs. On recommended hardware too. 
I’ll give up this for now and redo my system and all templates manually. It will probably take a month, but that is life in our great reset era.
If posting the logs somewhere might help future installers, please tell me where to post those.
1 Like
You can drop .log files here on the forum’s editor. They will show as attachments.
Or you can use details: (from the editor’s 
menu)
something.log
some random log line
some random log line 2
....
The issue with the details thing is that you easily exceed the post’s max characters (32000) I think.