[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Whonix Desktop Installer with Calamares - field report

This is what I do: I test everything in a (copied) version of the raw file that I boot in KVM. I test stuff in persistent/live-mode and one things seem clean, I make the needed adjustments in the master raw and then only the ISO file. Remastering the ISO file each time would be very long. This error was very difficult to debug because it was very generic, and can be caused by a ton of different things. Eventually, I just did a diff between all files installed in the previous hardened version and in the whonix-host to see what changed…

If we want a hardened-debian VM, I think user should be created. If we want an live ISO-installer, then no. So --flavor whonix-host should trigger the skipping of user creation, while all other flavours should create it as was the case before (don’t know if clear enough - easy to do?).

I read somewhere that they have to be deleted on debian during the install otherwise the install would not be bootable… Obviously needs some more testing/research.

Maybe, but I suspect that this file needs at least these settings:

<?xml version="1.0" encoding="UTF-8"?>

<channel name="xfce4-session" version="1.0">
  <property name="general" type="empty">
    <property name="FailsafeSessionName" type="string" value="Failsafe"/>
  </property>
  <property name="sessions" type="empty">
    <property name="Failsafe" type="empty">
      <property name="IsFailsafe" type="bool" value="true"/>
      <property name="Count" type="int" value="5"/>
      <property name="Client0_Command" type="array">
        <value type="string" value="xfwm4"/>
      </property>

And now:

<?xml version="1.0" encoding="UTF-8"?>

<channel name="xfce4-session" version="1.0">
  <property name="general" type="empty">
    <property name="SaveOnExit" type="bool" value="false"/>
  </property>
</channel>

Can’t we keep the default one?

Great!

OK would it be feasible to ship this particular file with another package? Or just writing it during build?

Great, I’ll try a build now!

2 Likes

Just built Whonix-Host-XFCE 15.0.0.2.8-developers-only

XFCE still broken because of misconfigured xfce4-session.xml.whonix file.

Once corrected, everything seems to be fine. Debian Live User is created on boot.

Didn’t try out the installer yet, but should be fine too I guess.

Theming is still broken though, but I understand it is not a priority right now.

Other issues still need to be addressed (see my posts above, passwordless sudo rights for Live User, etc.).

Almost operational :slight_smile:

1 Like

Trying out the Calamares Installer on this new build (in KVM, not on real hardware).

Installation failed in job packages:
Command 'apt-get --purge -q -y remove live-boot live-boot-doc...' returned non-zero exit status 100
-> it fails because it doesn’t find the packages live-config-doc, live-task-localisation and live-boot-doc in the ISO (and thus in the install target where it extracted the filesystem.squashfs image of the ISO file).

Did you remove them from the list of installed packages? Or they are in --no-install dependencies mode?

Anyway, removing these packages from the/etc/calamares/modules/packages.conf.whonix file solves the problem. So I guess that is sufficient.

This version works:

backend: apt

operations:
   - remove:
      - 'live-boot'
      - 'live-config'
      - 'live-config-systemd'
      - 'live-config-systemd'
      - 'live-tools'
      - 'calamares'
      - 'calamares-settings-debian'
EOF
1 Like

onion_knight via Whonix Forum:

  • File /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml.whonix
    breaks XFCE4, needs to be corrected (in the meantime I just did mv /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml.dpkg-new /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml)

onion_knight via Whonix Forum:

Can’t we keep the default one?

I merged the Debian one, and Whonix modifications into one. The result
is here:

Not sure if this is what you meant? Hopefully that works. The change by
Whonix looks of medium importance, disabling session saving. Not yet tested.

I’ll process a few more easy to add fixes in new posts to come soon, and
then create a new git tag.

No.

Yes. Have to use this.

Fixed.

Package xfce4-session also owns file

/etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml

Package xfce4-settings also owns file:

/etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml

/etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml lxqt-common

etc.

I did undo all the port form /etc/skel to /etc/xdg.

If we want a hardened-debian VM, I think user should be created. If we want an live ISO-installer, then no. So --flavor whonix-host should trigger the skipping of user creation, while all other flavours should create it as was the case before (don’t know if clear enough - easy to do?).

Will be covered by https://phabricator.whonix.org/T913

Any idea how the systemd unit file would detect that we are booting into
calamares so it will skip and not create user user?

Maybe, but I suspect that this file needs at least these settings:

<?xml version="1.0" encoding="UTF-8"?>

<channel name="xfce4-session" version="1.0">
  <property name="general" type="empty">
    <property name="FailsafeSessionName" type="string" value="Failsafe"/>
  </property>
  <property name="sessions" type="empty">
    <property name="Failsafe" type="empty">
      <property name="IsFailsafe" type="bool" value="true"/>
      <property name="Count" type="int" value="5"/>
      <property name="Client0_Command" type="array">
        <value type="string" value="xfwm4"/>
      </property>

And now:

<?xml version="1.0" encoding="UTF-8"?>

<channel name="xfce4-session" version="1.0">
  <property name="general" type="empty">
    <property name="SaveOnExit" type="bool" value="false"/>
  </property>
</channel>

Can’t we keep the default one?

This should be solved by:

OK would it be feasible to ship this particular file with another package? Or just writing it during build?

whonix-base-files can continue to ship
/etc/default/grub.d/30_whonix.cfg. User user creation will be sorted
out in https://phabricator.whonix.org/T913

1 Like

onion_knight via Whonix Forum:

XFCE still broken because of misconfigured xfce4-session.xml.whonix file.

That should be fixed in
https://github.com/Whonix/whonix-xfce-desktop-config and in next Whonix
tag yet to be created.

Theming is still broken though, but I understand it is not a priority right now.

Not really anything sorted by priority yet. all needs implementation.

https://phabricator.whonix.org/project/board/145/

https://phabricator.whonix.org/project/view/26/

https://phabricator.whonix.org/project/view/132/

Other issues still need to be addressed (see my posts above, passwordless sudo rights for Live User, etc.).

I should have created tickets for all of that?

Please have a look at:

https://phabricator.whonix.org/feed/

Please kindly create tickets for any missing items.

It’s rather difficult to take action based on forum posts for me if it
is getting complex and convulsed with a bunch of tasks that require
different work such as research, implementation, build, testing that all
easily take more than 1 hour of time.

1 Like

Didn’t see that until now becuase no one copied me. Seems that dnsmasq package is missing on Whonix Host which prevents the network from starting NAT successfully.

1 Like

Should dnsmasq then be part of the https://www.whonix.org/wiki/KVM guide?

dnsmasq is a DHCP server. Security issue having it installed on the host? Can be reconfigured to serve KVM only? If yes, any alternative without dnsmasq?

If ok or no alternative, could you add to Depends: please here:

Scratch that, That was a wrong guess. Tested libvirt/KVM install on Buster and dnsmasq-base is one of the automatically installed deps of libvirt. There are no security problems with the way libvirt uses and confgures it. It is otherwise not active for external interfaces. (links about that will be posted shortly in the DHCP thread).

I have no idea what other reason causes Whonix-External to fail. Let’s deal with it when other blockers are solved.

1 Like

HulaHoop via Whonix Forum:

I have no idea what other reason causes Whonix-External to fail. Let’s deal with it when other blockers are solved.

Only start is failing inside chroot but start inside chroot is not
important at all as long as start works when the image gets actually booted.

1 Like

Could calamares be configured to somehow not create user user during boot instead? That would simplify implementation on the Whonix side a lot.

Then we might be able to use /usr/share/pam-configs/mkhomedir ( http://blog.dailystuff.nl/2012/07/create-home-directory-on-first-login/ ) which would also solve https://phabricator.whonix.org/T913 / bug: not all files form /etc/skel are copied to /home/user.

( sudo pam-auth-update --enable mkhomedir )

Hi @Patrick

I am not sure I understand what you ask.

Here is how it works last time I tested:

-> Starting “Whonix-Desktop-with-Calamares-Installer” in live-mode: live-user is created on boot if correct kernel flags or appended (so already working)
-> Using Calamares-Installer: the user creates a user for his new machine he is installing Whonix-Desktop on (is this what you would like to suppress?)

1 Like

Just to let you know that I am currently rebuilding from scratch with version 15.0.0.3.3.

1 Like

Good question. :slight_smile: If I remember right, you previously said, that calamares gets confused by user user already being created during live boot. Therefore you manually deleted account user user before creating the iso.

Therefore we concluded that user user should be created during first boot of Whonix rather than during build of Whonix. However, also in live mode user user creation should not be done by Whonix anon-base-files.postinst but by calamares.

I guess what I am asking is, is it possible to make calamares not get confused by an already existing user user account?

What’s the name of that user account? user user? I guess not? Probably live-something? That should not really matter since it does not interfere with anything.

Yes. Ideally that would also be left to anon-base-files.postinst?

Currently for non-live Whonix builds as per git master anon-base-files.postinst creates user user with --no-create-home, uses pam-auth-update --enable mkhomedir, thereby populates the home folder on first login.

Also anon-base-files.postinst locks root account as per Restrict root access for new builds by default so calamares don’t need to ask about root account either.

I don’t know the calamares requirements and how we could design this interaction. Should we support users choosing arbitrary user account names in the installer? Self-chosen passwords right in the installer or enough after they login first?

So the more calamares (except for live-something user in live mode perhaps?) can be configured to stay out, the easier it would be from the Whonix side. Otherwise anon-base-files.postinst user user creation part would have to be converted to a systemd unit file which is more complicated.

I’ve just built a Whonix-Desktop-Calamares-ISO based on 15.0.0.3.3 (sudo -E /home/user/Whonix/whonix_build --build --redistribute --target iso --flavor whonix-host-xfce --freedom false).

By default, the ISO boots in live-mode with user Debian Live user (identified as user).

In my understanding, this behaviour is not caused by Calamares (which is merely the OS install program), but by live-config (see content of /lib/live/config/ directory).

It doesn’t seem that the installer is getting confused by this in any way.

When booting into the newly installed OS (“Whonix-Desktop”), there is no user user available (I created a user with another username).

su user
su: user user does not exist

Debian Live user

I see. As of now, anon-base-files.postint is used during first boot of Whonix-Gateway and Whonix-Workstation, right?

I don’t know yet how to integrate this into Calamares. Maybe we could avoid it altogether in the Whonix-Desktop-ISO build? Is it necessary for the Whonix-Desktop?

As a reminder, this is what currently happens by default on Whonix-Desktop-ISO build 15.0.0.3.3:

all this tested only in KVM VM only, not yet on real hardware

-> boot with ISO in live-mode, with user Debian Live user, identified as user
-> Calamares Installer lets the user choose install configuration: encryption, username, password, same password for root account (=the username has sudo rights) or different password for root account, time zone, keyboard language, etc.
-> after install, when booting on the newly installed Whonix-Desktop (hard disk, no ISO), the only interactive user available is the one created during the Calamares install (as expected). It has a home folder with Desktop Pictures and Downloads directories. I guess its environment is being copied from /etc/skel?
-> there is however a /home/user/ directory, which is empty…

Side note: I have some bugs to report regarding, I’ll do it later, probably tomorrow.

Easy answer first, might have more answers later.

ls -la /home/user

?
Completely empty? Nothing inside?
I will review what might be causing this.

No. anon-base-files.postinst is run during installation of the anon-base-files package which happens during image creation inside chroot at build time.

That is, if you have the anon-base-files package installed. Do you have the anon-base-files package installed?

If you are building Whonix host you will be installing meta package whonix-host-xfce-kvm-freedom / whonix-host-xfce-kvm-nonfreedom so anon-base-files might not be installed. This could be considered a feature, not a bug depending on how we want to design it. Whonix host might need a different but similar package. On the other hand, I guess anon-base-files on Whonix host is a good idea?

No, it is not empty:

root@test-pc:~# tree -a /home/user/
/home/user/
└── .cache
    └── virt-manager
        └── virt-xml.log

and:
cat /home/user/.cache/virt-manager/virt-xml.log

[Mon, 15 Jul 2019 13:04:36 virt-xml 13047] DEBUG (cli:200) Launched with command line: /usr/share/virt-manager/virt-xml Whonix-Gateway --add-device --filesystem source=/mnt/gateway-shared,target=shared,type=mount,accessmode=mapped
[Mon, 15 Jul 2019 13:04:36 virt-xml 13047] DEBUG (cli:214) Requesting libvirt URI default
[Mon, 15 Jul 2019 13:04:36 virt-xml 13047] DEBUG (cli:217) Received libvirt URI qemu:///system
[Mon, 15 Jul 2019 13:04:36 virt-xml 13047] DEBUG (virt-xml:53) XML diff:
--- Original XML
+++ Altered XML
@@ -96,5 +96,9 @@
       <backend model="random">/dev/urandom</backend>
       <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/>
     </rng>
+    <filesystem type="mount" accessmode="mapped">
+      <source dir="/mnt/gateway-shared"/>
+      <target dir="shared"/>
+    </filesystem>
   </devices>
 </domain>

[Mon, 15 Jul 2019 13:04:36 virt-xml 13048] DEBUG (cli:200) Launched with command line: /usr/share/virt-manager/virt-xml Whonix-Workstation --add-device --filesystem source=/mnt/workstation-shared,target=shared,type=mount,accessmode=mapped
[Mon, 15 Jul 2019 13:04:36 virt-xml 13048] DEBUG (cli:214) Requesting libvirt URI default
[Mon, 15 Jul 2019 13:04:36 virt-xml 13048] DEBUG (cli:217) Received libvirt URI qemu:///system
[Mon, 15 Jul 2019 13:04:36 virt-xml 13048] DEBUG (virt-xml:53) XML diff:
--- Original XML
+++ Altered XML
@@ -93,5 +93,9 @@
       <backend model="random">/dev/urandom</backend>
       <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/>
     </rng>
+    <filesystem type="mount" accessmode="mapped">
+      <source dir="/mnt/workstation-shared"/>
+      <target dir="shared"/>
+    </filesystem>
   </devices>
 </domain>

It has been copied over from the ISO file, meaning it somehow survived the cleaning phase at build time.

Other observations regarding Whonix-Desktop-Calamares-Installer-ISO-15.0.0.3.3:
All tests done with KVM, not real hardware

Whonix-ISO (=BEFORE install, using the live ISO only)

  1. Theming is not OK
    It uses default debian buster theming:

  2. Trying to use Whonix-VM with virt-manager results in fatal error
    Error starting network 'Whonix-External': Unable to create bridge virbr1: Package not installed
    Same thing for virtual network Whonix-Internal.
    Virtual network ‘default’ fails with
    Error starting network 'default': internal error: Network is already in use by interface ens3

  1. Calamares Installer branding must be changed
    It is now using default debian buster branding. I already have suggestions to change the branding, will post in another thread.

Whonix-Desktop on HDD (=AFTER install, without the live ISO)

  1. Residual files in /home/user/
    As mentioned above:

    root@test-pc:~# tree -a /home/user/
    /home/user/
    └── .cache
    └── virt-manager
    └── virt-xml.log

  2. Newly installed user cannot log in as root or execute a command with sudo rights
    This is probably the worst bug of the list. I have no idea where it comes from. It seemed to work last time I did a full build and test… Didn’t dig further, here are the outputs:

Trying to use sudo with sudo rights always fails with “incorrect password” (although it is correct):

test@test-pc:~$ sudo ls

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for q:    
Sorry, try again.
[sudo] password for q:     
Sorry, try again.
[sudo] password for q:      
sudo: 3 incorrect password attempts

su command always gives a “Permission denied” error…

test@test-pc:~$ su -
Password: 
su: Permission denied

As I said, I didn’t dig further. Any ideas on how to investigate and solve this weird faulty behavior are welcome.

  1. Trying to use Whonix-VM with virt-manager results in fatal error (same error as with ISO)
    Error starting network 'Whonix-External': Unable to create bridge virbr1: Package not installed
    Same thing for virtual network Whonix-Internal.
    Virtual network ‘default’ fails with
    Error starting network 'default': internal error: Network is already in use by interface ens3

  2. There seems to be a problem with clock synchronization (lagging one hour behind).

1 Like

Sure you are not building from git master?
There was work on this:
Restrict root access
These are not yet tested in a new build and might cause some issues.

Does /var/lib/dpkg/info/anon-base-files.postinst contain passwd? To check:

cat /var/lib/dpkg/info/anon-base-files.postinst | grep 

This would mean you build from git master.

passwd
## mkpasswd
passwd --lock “$account_to_be_locked”
#sudo passwd

@onion_knight:

/home/user/.cache/virt-manager/virt-xml.log

Any idea which might be creasing those? @HulaHoop

Also can you help please with these KVM issues? @HulaHoop

https://github.com/Whonix/whonix-initializer/blob/master/usr/lib/anon-dist/chroot-scripts-post.d/80_cleanup does not attempt to clean the home folder yet.

Maybe soon we move to http://blog.dailystuff.nl/2012/07/create-home-directory-on-first-login/ / sudo pam-auth-update --enable mkhomedir. During that I will work on it.

Timezone issue? Sometimes it is a “BIOS” (virtual or real BIOS) vs system clock issue.
Is package timezone-utc installed? I guess we want to go for that?

OK as per the official guide there is a virtinst package needed for creating/cloning VMs via commandline. Please install and let me know if it works.

https://wiki.debian.org/KVM#Installation

1 Like