Project

General

Profile

Feature #12403

Make Tails work nicely inside of Qubes OS, without big paradigm shifts

Added by Dr_Whax over 2 years ago. Updated 8 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
03/26/2017
Due date:
% Done:

10%

Feature Branch:
wip/feature/12403-qubes-support
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

During Tor-dev, we've decided on getting Tails 3.x+ to work nicely inside of Qubes without having to change lots of things. For the moment that would mean, getting Tails to work nicely in an Qubes HVM.

This would mean something like the following:

  • Install Qubes-tools inside Tails

Having the Qubes-tools installed might mean that we have an easier way to set up networking, since there is no DHCP server available.

We also would need to decide on a way to have persistent storage on Qubes when running Tails.

See the Running Tails in Qubes doc on the Qubes OS website.


Related issues

Related to Tails - Feature #12104: Decide whether we can drop DKMS modules support Rejected 01/01/2017
Related to Tails - Feature #16111: Gateway support - Whonix and Invizbox Duplicate 11/09/2018

History

#1 Updated by intrigeri over 2 years ago

  • Status changed from New to Confirmed

#2 Updated by intrigeri over 2 years ago

  • Subject changed from Make Tails work nicely inside of Qubes, without big paradigm shifts to Make Tails work nicely inside of Qubes OS, without big paradigm shifts

#3 Updated by anonym over 2 years ago

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 over 2 years ago

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

#5 Updated by anonym over 2 years ago

  • Feature Branch set to feature/qubes-support

Dr_Whax wrote:

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.

Cool!

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

We should contact Marek and/or unman (Debian template maintainer, who supposedly solved this exact problem back when HVM was used) on the qubes-devel mailing list to get help with the above things so we get qubes-{core,gui}-agent working properly. Also, at the moment booting Tails with those packages installed breaks the boot even outside of Qubes, which we cannot allow if we'd ship these in all Tails ISOs.

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

The current branch does these two things.

#6 Updated by anonym over 2 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Feature Branch changed from feature/qubes-support to wip/feature/12403-qubes-support

#7 Updated by anonym over 2 years ago

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 over 2 years ago

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.

#9 Updated by intrigeri over 2 years ago

  • Related to Feature #12104: Decide whether we can drop DKMS modules support added

#10 Updated by intrigeri over 2 years ago

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

#11 Updated by intrigeri over 2 years ago

intrigeri wrote:

Note that building the u2mfn kernel module requires dkms support, which will conflict with grsec (#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 (#12104#note-12) for VirtualBox.

#12 Updated by cypherpunks over 2 years ago

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 over 2 years ago

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 u almost 2 years ago

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!

#15 Updated by u over 1 year ago

  • QA Check set to Info Needed

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

#16 Updated by intrigeri about 1 year ago

  • Related to Feature #16111: Gateway support - Whonix and Invizbox added

#17 Updated by intrigeri 8 months ago

  • Description updated (diff)
  • Assignee deleted (Dr_Whax)
  • QA Check deleted (Info Needed)

@Dr_Whax, I'll assume you're not going to work on this soon, so let's make it clear this ticket is up for grabs by anyone interested :)

Also available in: Atom PDF