I have imported the xml files for the whonix gateway and workstation, and they’re both running on my headless server. How do I manage them now and enter their filesystems? I can’t SSH into them. I tried running # virsh console Whonix-Gateway, but get this error:
error: internal error: cannot find character device null
Should I edit the xml file? I didn’t want to do that without knowing for sure it won’t mess something up, so figured I’d post. Thanks.
Sounds interesting. Do you think this could be supported by default or is there a security risk? @HulaHoop
@Patrick I have not found any security warnings about this. Interesting is an understatement. This essentially gives us Whonix-KVM-cli without having to do an extra build (or am I missing something?). If a user doesn’t want the GUI they can dial back the RAM on the GW to as little as 200MB and the GUI won’t show. Also doing “Send Key → Ctrl + Alt +F2” will exit the GUI session.
We can support this out of the box by shipping a modified grub, pre-started getty service and adding the devices to the VM config. I have successfully tested the steps below.
@foieac5 Yes there is a serial device that needs to be added in the XML or from virt-manager. You also need to start a service and edit grub in the guest VM you want to attach the console too.
Here are the steps which I will add to the wiki shortly:
virtualization - virsh: VM console does not show any output - Server Fault
virtualization - virsh: VM console does not show any output - Server Fault
systemctl enable serial-getty@ttyS0.service
systemctl start serial-getty@ttyS0.service
in guest VM in /etc/default/grub replace
GRUB_CMDLINE_LINUX_DEFAULT=“quiet”
#GRUB_TERMINAL=console
by
GRUB_CMDLINE_LINUX_DEFAULT=“console=tty0 console=ttyS0”
GRUB_TERMINAL=“serial console”
guest# update-grub
the VM console for running VM can be get by
host# virsh console VM
XML
<controller type='virtio-serial' index='0'/>`
<serial type='pty'>
<target port='0'/>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>
<channel type='spicevmc'>
<target type='virtio' name='com.redhat.spice.0'/>
<address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>
Edit by Patrick:
Ok, I edited the XML file and ran the two systemctl commands, but how do I get into the Whonix-Gateway filesystem to edit /etc/default/grub ?
I did so using the GUI virt-manager console, but I can see the catch 22 you’re in since you are running the host headless too which means you have no alternative way to access the files in the guest. Hopefully when we do the changes in the future, you won’t have to experience that.
Damn, I need to do this. Would building from source and editing that file be a valid option?
@Patrick what is the best way to add a custom grub config to source? Do we use a .d snippet or should he edit this file directly?
Perhaps you could mount the qcow2 disk to modify it. Changes would have
to end up in /boot/grub/grub.cfg since it is auto generated. Non-trivial.
HulaHoop via Whonix Forum:
in guest VM in /etc/default/grub replace
Please use drop-in folder /etc/default/grub.d please (as per
Configuration Files - Kicksecure ).
Not sure about the exact file name yet.
/etc/default/grub.d/30_serial_console.cfg
HulaHoop via Whonix Forum:
@Patrick I have not found any security warnings about this.
Let’s do this for Whonix KVM VM builds only for now.
Interesting is an understatement. This essentially gives us Whonix-KVM-cli without having to do an extra build (or am I missing something?).
If a user doesn’t want the GUI they can dial back the RAM on the GW to as little as 200MB and the GUI won’t show.
Wasn’t this the case before already?
Also doing “Send Key → Ctrl + Alt +F2” will exit the GUI session.
We can support this out of the box by shipping a modified grub, pre-started getty service and adding the devices to the VM config. I have successfully tested the steps below.
Yes.
@foieac5 Yes there is a serial device that needs to be added in the XML or from virt-manager. You also need to start a service and edit grub in the guest VM you want to attach the console too.
Please add the xml modifications to whonix-libvirt package. @HulaHoop
systemctl enable serial-getty@ttyS0.service
systemctl start serial-getty@ttyS0.service
This has to become a drop-in file in systemd system drop-in folder
/lib/systemd/system. @HulaHoop
in guest VM in /etc/default/grub replace
GRUB_CMDLINE_LINUX_DEFAULT=“quiet”
quiet is removed by
https://github.com/Whonix/grub-output-verbose/blob/master/etc/default/grub.d/30_output_verbose.cfg
already
#GRUB_TERMINAL=console
by
GRUB_CMDLINE_LINUX_DEFAULT=“console=tty0 console=ttyS0”
GRUB_TERMINAL=“serial console”
Some redundancy here? Can this perhaps be shortened? Just one of the two
variables? Just console=tty0 or just console=ttyS0 or both required?
guest# update-grub
This would later be automated by something like this:
https://github.com/Whonix/grub-output-verbose/blob/master/debian/grub-enable-apparmor.postinst#L22
HulaHoop via Whonix Forum:
@Patrick what is the best way to add a custom grub config to source?
For a clean, redistributable implementation:
grub-something as package name since this is not only grub config.whonix-libvirt package might get installed on Whonix host where wewhonix-libvirt does not fit.kvm / libvirt something since also not tied to these.serial-console-enable?Do we use a .d snippet or should he edit this file directly?
Certainly .d. This can be all implemented using drop-in config files.
foieac5 via Whonix Forum:
Would building from source and editing that file be a valid option?
Yes but non-trivial for users. Unsupported.
Unless there is a non complicated way to include KVM only changes in source let’s add all the necessary internal plumbing for now and simply tell other hypervisor users not to attach a console if they don’t want to.
Back to security, I guess the hypothetical bug of a console vuln is possible as discussed before but these types of bugs were rooted out in the early years of the millennium. I would guess the surface attack of a cli onsole is much smaller than the GUI console.
Both required because it would boot the VM in cli mode otherwise
- package name
serial-console-enable?
Yes sounds good.
Roughly what time would that be available? In the meantime is there absolutely no supported way to run Whonix headless?
foieac5 via Whonix Forum:
Roughly what time would that be available?
No ETA.
HulaHoop via Whonix Forum:
Unless there is a non complicated way to include KVM only changes in source
Non-issue. Can be done same as, see previous discussion on spice-vdagent.
(
https://github.com/Whonix/Whonix/blob/master/build-steps.d/1700_install-packages#L302
)
let’s add all the necessary internal plumbing for now and simply tell other hypervisor users not to attach a console if they don’t want to.
Further development work. Non-trivial. Might not even be possible.
Enable serial console everywhere would mean to enable it also for
physical isolation builds, and then when something goes unexpected “why
did Whonix enable serial console access by default” is a hard question
to answer.
Back to security, I guess the hypothetical bug of a console vuln is possible as discussed before but these types of bugs were rooted out in the early years of the millennium. I would guess the surface attack of a cli onsole is much smaller than the GUI console.
The only issue might be physical isolation or perhaps remote VMs where
this one disabled regular tty console login and then would be surprised
by the extra default serial console access.
Not even necessary then. I typed that before seeing it can be all done for KVM only in an isolated package which I can work on.
It’s born.
Untested. Please test in Whonix 15.
Run sudo update-grub (to have a system generated version rather than prestine).
Get a copy of /boot/grub/grub.cfg for later comparison or put under git version control.
sudo systemctl list-units | grep getty > old
Build and install the package.
There is a lintian warning.
E: serial-console-enable: service-file-is-not-a-file lib/systemd/system/getty.target.wants/serial-getty@ttyS0.service
It can be safely ignored. That warning will be silenced later when we know this implementation works.
Install the package.
Compare the newly generaetd /boot/grub/grub.cfg with the backup and see if the desired changes are made.
save list of running systemd unit files for later comparison
sudo systemctl list-units | grep getty > new
Reboot required (to make grub changes take effect, also there is no code to run the new systemd unit file without reboot but it’s not useful anyhow since this requires reboot anyhow).
compare the systemctl output to check if the new systemd unit file is load
meld old new
(or any other diff viewer of your choice)
Is it in the repo? apt can;t find it. I’ll test it when it is.
Not in repo yet.