Tails

#3 Updated by anonym 2017-03-26 12:40:40

Once qubes-core-agent is installed the following command will only succeed if run inside Qubes OS:

qubesdb-read /qubes-vm-type

We can use this to not warn about running inside a virtual machine when booting inside Qubes OS, and other special treatment.

#4 Updated by Dr_Whax 2017-03-26 13:54:55

anonym wrote:
> Once qubes-core-agent is installed the following command will only succeed if run inside Qubes OS:
> […]
> We can use this to not warn about running inside a virtual machine when booting inside Qubes OS, and other special treatment.

Output of that is: `HVM` as expected.

Having a Tails 3.0 beta iso build with Qubes tools doesn’t start a graphic environment for the moment. It seems what we’re missing at the moment is:

• u2mfn kernel module
• dummy-hcd kernel module
• Deleting the user: user that is the default in Qubes. Then it creates the `amnesia` user just fine.
• qubes-video package

#7 Updated by anonym 2017-03-26 22:40:47

I found the Installing kernel in Debian VM docs, and the u2mfn kernel module is now built in the branch, apparently we can safely ignore errors about dummy-hcd.

It would be interesting to see how an ISO built from this branch boots in Qubes; DrWhax?

When booted in kvm the boots gets stuck unless I add rootpw=asdf nosplash break=bottom to the kernel command-line, and chroot /root in the initramfs shell and then:

systemctl disable qubes-db.service
systemctl disable qubes-sysinit.service

At least this leads to a console login, and I can then start gdm.service. Tails Greeter appears, but logging in gets stuck; I think some stuff about the user (actually named “user”) added by the qubes packages is the cause.

BTW, when building this branch you’ll currently get a configuration conflict for /etc/fstab — until this is solved, just pick option N (keep current version) in the interactive prompt.

#8 Updated by Dr_Whax 2017-03-27 12:04:51

anonym wrote:
> I found the Installing kernel in Debian VM docs, and the u2mfn kernel module is now built in the branch, apparently we can safely ignore errors about dummy-hcd.
>
> It would be interesting to see how an ISO built from this branch boots in Qubes; DrWhax?
>
> When booted in kvm the boots gets stuck unless I add rootpw=asdf nosplash break=bottom to the kernel command-line, and chroot /root in the initramfs shell and then:
> […]
> At least this leads to a console login, and I can then start gdm.service. Tails Greeter appears, but logging in gets stuck; I think some stuff about the user (actually named “user”) added by the qubes packages is the cause.
>
> BTW, when building this branch you’ll currently get a configuration conflict for /etc/fstab — until this is solved, just pick option N (keep current version) in the interactive prompt.

Cool, will attempt a build one of these days.

#10 Updated by intrigeri 2017-04-01 06:40:12

Note that building the u2mfn kernel module requires dkms support, which will conflict with grsec (Feature #12104) for the foreseeable future.

#11 Updated by intrigeri 2017-04-01 06:43:31

intrigeri wrote:
> Note that building the u2mfn kernel module requires dkms support, which will conflict with grsec (Feature #12104) for the foreseeable future.

… unless we can detect the Qubes platform and boot a non-grsec kernel on it, just like what we’re considering doing (Feature #12104#note-12) for VirtualBox.

#12 Updated by cypherpunks 2017-04-03 02:06:42

It would also be neat to do something similar to Whonix, running the Tor process in a lighter, isolated VM in Qubes, so a compromise of the Tails VM would not bypass Tor. On a random note, perhaps Xen would be able to emulate UMIP to improve the security of Tails, just slightly.

#13 Updated by intrigeri 2017-04-03 04:53:49

> It would also be neat to do something similar to Whonix, running the Tor process in a lighter, isolated VM in Qubes, so a compromise of the Tails VM would not bypass Tor.

Yeah. It’s outside of the scope of this ticket though (note the “without big paradigm shifts” in the title :)

#14 Updated by Anonymous 2018-01-19 10:54:21

Building the u2mfn kernel module requires dkms support but should not conflict with grsec anymore, because we won’t ship grsec.

Dr_Whax: may you please try to see/resume what is left to be done here? Thanks!