Clean Reinstall + Install Packages and Previous Configs as a Way of Backup/Restore Process

[enmus]

I am not sure I am clear if what I want is feasible, nor if i will ask it properly.
I certainly know that keeping in mind Qubes’ philosophy that qubes are compromised by default, there’s no point in restoring backup over clean install. Unavoidable bloating is another reason not to restore.

So, for the start, is there a way to compare my current dom0 state with the one provided by .iso (I know 'default" state is relative term, but I have to start somewhere) by getting human readable text?

The idea is that by comparing those two, I’d revise which packages once manually installed I want again over clean install, which I wouldn’t want again, which preferences and tweaks to apply again, and which don’t.

I read a lot about this for days but couldn’t get further then dconf dump and that doesn’t look enough. Any pointers will be appreciated.

[adw]

@enmus

keeping in mind Qubes’ philosophy that qubes are compromised by default

Just to clarify, we do not assume that every qube is compromised by default, since then it would be impossible to do anything securely with the system. Rather, certain untrusted qubes, such as sys-net, are treated as though they are already compromised.

@enmus

there’s no point in restoring backup over clean install

I don’t think this is true. Besides, if it were true, it would make it impossible to meaningfully restore data from a backup.

@enmus

So, for the start, is there a way to compare my current dom0 state with the one provided by .iso (I know 'default" state is relative term, but I have to start somewhere) by getting human readable text?

I’m not aware of any such thing, nor can I even imagine how it might be accomplished in a practical way.

@enmus

The idea is that by comparing those two, I’d revise which packages once manually installed I want again over clean install, which I wouldn’t want again, which preferences and tweaks to apply again, and which don’t.

It seems to me that such an approach is unlikely to provide any meaningful security benefits.

[Sven]

@enmus asked:

compare my current dom0 state with the one provided by .iso

Let me answer by clarifying what the Qubes OS provided backup/restore covers:

• qubes incl. templates, standalones with their respective settings
• the /home directory of dom0

It does not:

• backup the rest of dom0
• restore anything you installed in dom0

When you do a fresh install of Qubes OS and you run a restore, you get your qubes with their settings back and you get a new directory in your dom0 home that contains a copy of your previously backed up dom0 home. It is then upon you to manually copy from that restore location back into your actual home.

Hence I think the motivation for your question was maybe a misunderstanding of what restore would do?

[mono]

Do you know why the Qubes Backup tool shows currently 8GB+ for dom0 when doing a Backup?
This is probably confusing if only the dom0 /home directory is backed up which in my case is pretty empty.
Maybe the Backup tool could be configured to show the actual size of /home and/or include a bit more Text,

dom0 (/home directory only)

[fsflover]

Compromise recovery in Qubes OS

[enmus]

Thanks all for your responses.

Everything would be easier if I made notes about changes in a timely manner, now I don’t have an idea in what all the ways I tweaked my Qubes… If I’d knew, I’d backup only data, not VMs themselves.

I’d start from here

@Sven

Hence I think the motivation for your question was maybe a misunderstanding of what restore would do?

I wouldn’t say so, but also wouldn’t exclude you were right.

I guess @fsflover recognized where I was heading to regarding domUs (although he liked adw’s post, so I’m not sure). I was planning to discuss that later, after defining suitable frame for “restoring” dom0 after clean install first. Sorry for I wasn’t clear enough (I was thought not to use “I was misunderstood” and that “others didn’t understand” was even worse).
Anyway, to clarify

@adw

we do not assume that every qube is compromised by default

I didn’t say anywhere every. I just didn’t elaborate it in details, trying to focus on dom0 first, although I don’t see anything wrong even someone who follows Qubes’ concept, to consider all qubes as compromised. Less dangerous than vice versa.

@adw

if it were true, it would make it impossible to meaningfully restore data from a backup.

Again, I didn’t speak about data, but about backup - of a certain qube in whole. Inside Qubes, I keep data only in vault, so I consider it meaningful to restore the data from a vault backup, but not the vault itself.
Why? Because it’s bloated with unnecessary packages, as I said it was the other main reason (when qubes aren’t compromised). Am I wrong or missing something with such constellation?

@adw

It seems to me that such an approach is unlikely to provide any meaningful security benefits.

Dom0 is bloated at the moment (“I’d revise which packages once manually installed I want again over clean install, … and which don’t.**”). Doesn’t such an approach mean smaller attack surface? So I thought I clearly saw security benefit from this?

And this is perfect to get back to my question about dom0.

@adw

@enmus

So, for the start, is there a way to compare my current dom0 state with the one provided by .iso (I know 'default" state is relative term, but I have to start somewhere) by getting human readable text?

I’m not aware of any such thing, nor can I even imagine how it might be accomplished in a practical way.

I was hoping to hear something like here but with Qubes specifics other then already mentioned, and it looks I’m not the only one searching for pointers with this. It’s not that we’re lazy to manually set all the tweaks and preferences again, it’s just what the second sentence in this post says.

Regarding dom0, as per fslover’s link in order to get

some number of potentially compromised VMs (those restored from the untrusted system),

some number of clean, non-compromised AppVMs.

and then to compare them back to back, while both running. I see here still possibility of channel side attacks by running potentially compromised restored VMs, but the article itself doesn’t address this.
in the article, in Summary section it is said that Qubes provide:

… 2) ability to safely migrate select data from compromised AppVM to new VMs

which I’m not clear about how the data in a compromised VM isn’t also compromise, but I anyway keep this on mind, too.

Thanks once again for your time.

[renehoj]

Can’t you use ‘rpm -aq --last’ and/or ‘dnf history userinstalled’ ?

There is probably also a good chance you can find the list of software you installed .bash_history

[enmus]

Thanks for the idea. Haven’t tested it, but in general it’s not a problem to get a list of installed packages. Preferences less, but tweaks are my biggest concern how to get them (most probably those set out of /etc and /rw).

[adw]

@enmus

@adw

if it were true, it would make it impossible to meaningfully restore data from a backup.

Again, I didn’t speak about data , but about backup - of a certain qube in whole. Inside Qubes, I keep data only in vault, so I consider it meaningful to restore the data from a vault backup, but not the vault itself.

When I say “data from a backup,” I just mean whatever bits are in the file. Could be a VM. Could be something else. In this sense, VMs are also data. In this case of the Qubes backup system, the data is VMs (which themselves contain other data).

@enmus

Why? Because it’s bloated with unnecessary packages, as I said it was the other main reason (when qubes aren’t compromised). Am I wrong or missing something with such constellation?

You can back up an app qube without backing up its template, so you’re not backing up any packages, just the app qube’s /rw/.

@enmus

@adw

It seems to me that such an approach is unlikely to provide any meaningful security benefits.

Dom0 is bloated at the moment (“I’d revise which packages once manually installed I want again over clean install, … and which don’t.**”). Doesn’t such an approach mean smaller attack surface? So I thought I clearly saw security benefit from this?

Maybe, but that seems like a completely separate topic from this thread (which I understood to be about backups).

[fsflover]

@enmus

I guess @fsflover recognized where I was heading to regarding domU s (although he liked adw’s post, so I’m not sure).

Indeed, you are right that there is some contradiction in my actions

@adw

Just to clarify, we do not assume that every qube is compromised by default, since then it would be impossible to do anything securely with the system.

According to my link above, it is very much possible to preserve some security even if all old qubes are compromised. For that, one could use the paranoid backup restore and carefully work with the data in compromised qubes. You can always create uncompromised qubes and redownload the templates as long as dom0 is not compromised.

@enmus

I’m not clear about how the data in a compromised VM isn’t also compromise,

The data in a compromised qube is indeed potentially compromised, but you can still copy it to a trusted qube without compromising it as long as you don’t run or parse this data with complicated algorithms (e.g., do not open pdf or MS Word files). You can also technically compare those files bit by bit with known good versions if you have them.
@adw Can’t you also do the latter action with /home directory in dom0 after the paranoid backup restore?

[adw]

@fsflover

@adw

Just to clarify, we do not assume that every qube is compromised by default, since then it would be impossible to do anything securely with the system.

According to my link above, it is very much possible to preserve some security even if all old qubes are compromised. For that, one could use the paranoid backup restore and carefully work with the data in compromised qubes. You can always create uncompromised qubes and redownload the templates as long as dom0 is not compromised.

But if you assume that every qube is compromised by default, then you can’t also assume that the new qubes you create on the fresh installation are uncompromised. That’s why the assumption is unreasonable, IMHO.

@fsflover

You can also technically compare those files bit by bit with known good versions if you have them.
@adw Can’t you also do the latter action with /home directory in dom0 after the paranoid backup restore?

If you already have a trusted copy of the data, what’s the point in checking a potentially-compromised version?

[fsflover]

@adw

if you assume that every qube is compromised by default

This is equivalent to either Qubes OS / dom0 to be compromised by default (i.e. you shouldn’t trust its developers) or every possible OS installable in Qubes is compromised. If one believes in the first case, one just stops using Qubes and switches to another OS. Second case looks like just a paranoia to me.

So I did not take into account both these cases when writing my comment above.

@adw

If you already have a trusted copy of the data, what’s the point in checking a potentially-compromised version?

For instance, if you prove that all files except one are not compromised, it’s pretty likely that this file is also clean. It’s just a question of probability.

[deeplow]

@enmus I’ve attempted to rewrite the title to be more explicit about the issue. But let me know if I totally butchered it and just change it back.

Let me say that I totally understand your reasoning for this. Actually, I did exactly what you suggested in your first post. When moving to 4.1 I didn’t restore the default templates.

Instead, I opted to reinstall all the software I had there. To do this I used commands like dnf history (on fedora templates) to see what else I had installed. There should be a similar one for debian.

Then I also looked at the file .bash_history to see the commands I had run on the template to recall any other changes. Since they are templates, I didn’t to a lot there so it was relatively simple.

In the future (and this is advanced stuff), you can take a look at saltstack. It’s a way for you to setup Qubes just the way you want it in a predictable way. In case you’re not familiar, think of it as a recipe for what qubes, packages and configurations you want. Then all you have to do is run it (even on a new system) and it sets everything up for you. (this is what Qubes uses internally to setup the whole system).

[KarlinQubes]

@deeplow

In the future (and this is advanced stuff), you can take a look at saltstack. It’s a way for you to setup Qubes just the way you want it in a predictable way. In case you’re not familiar, think of it as a recipe for what qubes, packages and configurations you want. Then all you have to do is run it (even on a new system) and it sets everything up for you. (this is what Qubes uses internally to setup the whole system).

That’s AWESOME!

[enmus]

@deeplow

Let me say that I totally understand your reasoning for this. Actually, I did exactly what you suggested in your first post. When moving to 4.1 I didn’t restore the default templates.

Thanks @deeplow for your post. It helped my sanity check to be confirmed.

@deeplow

Instead, I opted to reinstall all the software I had there.

Absolutely. The difference is that I started to use Qubes 4.1 from the early betas and without enough experience. So I started with the defaults, then installed all (un)necessary packages in the templates, only to then to discover disposables and how to use and customize them, after which I discovered minimals, then apt-cacher, then sys-audio, at the same time experimenting with Windows standalones, templates and its disposables, and now I have few more things to test and utilize, like sys-gui-gpu for example. Now, you can imagine what my Qubes looks like after all these testings. I must say here that whatever i did, I did it with high caution (didn’t connect to internet for a few weeks for example, and researching from the other computer), meticulously as possible (no single valuable data out of vault for example) and for all this time my Qubes was extremely stable and never crashed or freezes for a single time. But, bloated and compromised - most probably (Apper in dom0 or temporarily connecting some templates to the net for example - yes I know). As the last thing in this process is to prepare my data (but not the current state) for backup and restore. That’s how this topic was created.

@deeplow

Instead, I opted to reinstall all the software I had there. To do this I used commands like dnf history (on fedora templates) to see what else I had installed. There should be a similar one for debian.

Then I also looked at the file .bash_history to see the commands I had run on the template to recall any other changes. Since they are templates, I didn’t to a lot there so it was relatively simple.

Thanks for the tips. I want first to prepare dom0 with only the tweaks that I now find and am sure are needed or are useful (and your tips are applicable there too), after that the same for templates, and then to check tweaks for appVMs like bind dirs are for example…

@deeplow

In the future (and this is advanced stuff), you can take a look at saltstack.

That is my intention which would hopefully defy the purpose of this topic, and I’m trying, but very often it gets me feel like somehow there is a lack of documentation using it on Qubes, and especially on Qubes 4.1, like here for example. of course it is mainly due to I’m still don’t comprehend it enough to use it comfortably.

@deeplow

@enmus I’ve attempted to rewrite the title to be more explicit about the issue. But let me know if I totally butchered it and just change it back.

It’s great, but having on mind what we all wrote here, please consider if adding words “… as a way to backup/restore” at the end of how you edited it now would be with added value. Because I find your and mine tactic as a legit way to backup (data) and restore (desired state of the Qubes and its qubes). Having the title like that would hopefully help other users to at least consider to do it this way when thinking about backup and restore.

[deeplow]

@enmus

Because I find your and mine tactic as a legit way to backup (data) and restore (desired state of the Qubes and its qubes). Having the title like that would hopefully help other users to at least consider to do it this way when thinking about backup and restore.

Not sure I get what you mean, but by all means, please edit it if you feel it needs tweaking. It’s your post after all

[adw]

@deeplow

Instead, I opted to reinstall all the software I had there. To do this I used commands like dnf history (on fedora templates) to see what else I had installed. There should be a similar one for debian.

Then I also looked at the file .bash_history to see the commands I had run on the template to recall any other changes. Since they are templates, I didn’t to a lot there so it was relatively simple.

FWIW, this is also why the longstanding advice has been to keep a text file with notes about any customizations you make to your templates (e.g., non-default packages installed) so that you can more easily reapply them in the future. This is the low-tech, old school approach, whereas Salt is the high-tech, new-fangled approach.

[enmus]

I think I could bet no, at least regular, user would keep this on mind when starting to use Qubes, not to tell about salt.

[unman]

If you mean by this that no ordinary person can use Salt then you are
wrong.
If you mean that no ordinary user can use Salt without a good
introduction and help then you are (probably) right.

I think that the same applies to Qubes.

I’m not sure if you have lost that bet.

[KarlinQubes]

I’m very much not a technical user and in the next few days I am going to turn my mind to understanding & using Salt with Qubes, so I’ll post back with a dummies reaction to it.