'first-boot-completed' doesn't reflect appvm initial state

[tasket]

Qubes OS version:

R4.0

Affected component(s):

---

Steps to reproduce the behavior:

Create a new Linux appVM and start it.

Expected behavior:

The file /var/lib/qubes/first-boot-completed should reflect the date/time that the appVM was first initialized (/rw volume created).

Actual behavior:

The file /var/lib/qubes/first-boot-completed will have an old modification date (apparently from template initialization).

General notes:

This problem stems from the combination of using a root-fs directory /var/lib/qubes and only running touch on the file if it doesn't already exist.

I suggest removing the condition on touch at the end of /usr/lib/qubes/init/setup-rw.sh. Otherwise, a more accurate representation of VM initial state could be achieved with a different indicator that is created/touched when /usr/lib/qubes/init/setup-rwdev.sh detects a "virgin boot"; the new indicator could be called first-boot-started.

Obtaining the right indicators for init state is useful for Qubes-vm-hardening service.

---

Related issues:

[marmarek]

I suggest removing the condition on touch at the end of /usr/lib/qubes/init/setup-rw.sh.

That wouldn't really help, because then you'll effectively have boot time, not first boot time. The problem is that /var/lib/qubes/first-boot-completed lives on another volume that the thing it signals.
Moving this flag file to /rw/first-boot-completed would solve the problem.

BTW since we no longer copy private.img from template, you can use /rw filesystem creation time (sudo tune2fs -l /dev/xvdb).

Otherwise, a more accurate representation of VM initial state could be achieved with a different indicator that is created/touched when /usr/lib/qubes/init/setup-rwdev.sh detects a "virgin boot"; the new indicator could be called first-boot-started.

Do you mean an indicator "this is the first VM start"? /var/run/qubes/first-boot-started? (/var/run, because it will be automatically cleaned on shutdown - it's in tmpfs)

[marmarek]

I suggest removing the condition on touch at the end of /usr/lib/qubes/init/setup-rw.sh.

That wouldn't really help, because then you'll effectively have boot time, not first boot time. The problem is that /var/lib/qubes/first-boot-completed lives on another volume that the thing it signals.
Moving this flag file to /rw/first-boot-completed would solve the problem.

BTW since we no longer copy private.img from template, you can use /rw filesystem creation time (sudo tune2fs -l /dev/xvdb).

Otherwise, a more accurate representation of VM initial state could be achieved with a different indicator that is created/touched when /usr/lib/qubes/init/setup-rwdev.sh detects a "virgin boot"; the new indicator could be called first-boot-started.

Do you mean an indicator "this is the first VM start"? /var/run/qubes/first-boot-started? (/var/run, because it will be automatically cleaned on shutdown - it's in tmpfs)

[tasket]

Unfortunately can't trust the /rw fs including the creation time. So I'll handle this as a special case needing user input for now: tell user VM must be restarted for normal operation (after qubes-mount-dirs initializes /rw). Even though I can call mount-dirs.sh from my service, the result is a jammed UI I think bc /home/user needs more at that point than just /etc/skel and the UI services can't write to the immutable subdirs.

Moving indicators (I think one from setup-rwdev.sh and another from setup-rw.sh) to /var/run/qubes sounds good, as long as other stuff isn't looking in the old place (I grep'ed /usr/lib/qubes and didn't see anything). Once these are active, I can run some parts of my process late and handle the first-start situation automatically.

[tasket]

Unfortunately can't trust the /rw fs including the creation time. So I'll handle this as a special case needing user input for now: tell user VM must be restarted for normal operation (after qubes-mount-dirs initializes /rw). Even though I can call mount-dirs.sh from my service, the result is a jammed UI I think bc /home/user needs more at that point than just /etc/skel and the UI services can't write to the immutable subdirs.

Moving indicators (I think one from setup-rwdev.sh and another from setup-rw.sh) to /var/run/qubes sounds good, as long as other stuff isn't looking in the old place (I grep'ed /usr/lib/qubes and didn't see anything). Once these are active, I can run some parts of my process late and handle the first-start situation automatically.