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

How do I enter the whonix shell from cli

whonix-cli
#1

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.

#2

Sounds interesting. Do you think this could be supported by default or is there a security risk? @HulaHoop

2 Likes
#3

@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:

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>
1 Like
#4

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 ?

#5

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.

1 Like
#6

Damn, I need to do this. Would building from source and editing that file be a valid option?

#7

@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?

1 Like
#8

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
https://www.whonix.org/wiki/Configuration_Files ).

Not sure about the exact file name yet.

/etc/default/grub.d/30_serial_console.cfg
#9

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


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:

#10

HulaHoop via Whonix Forum:

@Patrick what is the best way to add a custom grub config to source?

For a clean, redistributable implementation:

  • please fork: https://github.com/Whonix/grub-output-verbose
  • rename all mentions of grub-output-verbose to a new package name
  • Not grub-something as package name since this is not only grub config.
  • any existing package? Unfortunately probably fits nowhere.
  • whonix-libvirt package might get installed on Whonix host where we
    don’t want this config. So whonix-libvirt does not fit.
  • Not kvm / libvirt something since also not tied to these.
  • package name 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.

1 Like
#11

foieac5 via Whonix Forum:

Would building from source and editing that file be a valid option?

Yes but non-trivial for users. Unsupported.

#12

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.

#13

Both required because it would boot the VM in cli mode otherwise

  • package name serial-console-enable ?

Yes sounds good.

#14

Roughly what time would that be available? In the meantime is there absolutely no supported way to run Whonix headless?

#15

foieac5 via Whonix Forum:

Roughly what time would that be available?

No ETA.

#16

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.

(


)

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.

#17

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.

1 Like
#18

It’s born.

https://github.com/Whonix/serial-console-enable

Untested. Please test in Whonix 15.

  1. Run sudo update-grub (to have a system generated version rather than prestine).

  2. Get a copy of /boot/grub/grub.cfg for later comparison or put under git version control.

  3. sudo systemctl list-units | grep getty > old

  4. 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.

  1. Install the package.

  2. Compare the newly generaetd /boot/grub/grub.cfg with the backup and see if the desired changes are made.

  3. save list of running systemd unit files for later comparison
    sudo systemctl list-units | grep getty > new

  4. 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).

  5. 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)

1 Like
#19

Is it in the repo? apt can;t find it. I’ll test it when it is.

#20

Not in repo yet.