Securing access to debug_shell from Raspberry Pi UART

kia_rst · March 24, 2021 at 5:13 PM

Hi everyone,

I've been successful on using the UART on Raspberry Pi 4 as a serial console by doing as below:

In cmdline.txt added:

console=serial0,115200 systemd.debug-shell=1

and in config.txt added:

enable_uart=1

Now an unsecured console is accessible from the UART pins and every time the system boots up, this shell is accessible without prompting for a password and this compromises the security of the system.

I've been searching around this for decades now and found no solutions so far about how to make this shell secure by making it ask for a password before giving root shell access to the connected user?

**HiassofT** · March 24, 2021 at 5:41 PM

As the debug-shell service description says this is only meant for debugging:

Code

debug-shell.service - Early root shell on /dev/console FOR DEBUGGING ONLY

To get a password prompt you'd need to run a getty, which isn't available in LE though.

so long,

Hias

kia_rst · March 25, 2021 at 10:43 AM

Thank you for the information.

Does something like system-tools provide a getty? Or any other way for installing one?

Or what your saying is, there is no way around this?

Maybe even using something rather than a debug-shell that would provide a shell with password prompt on UART?

I even had this idea that when we SSH into the system, the shell does prompt for a password. So it would be possible to do the same thing on UART (technically).

For example:

As I understood so far about the above code written in cmdline.txt, when I remove the debug-shell parameter, I get boot process output of LE on UART and no interactive shell, so I think what it does is it pipes the LE console output to the serial0 terminal and nothing more. Right?

In this case (just as an idea) would it be possible to pipe the SSH output to the serial0 terminal to get an interactive shell with password prompt as the SSH it self?

**HiassofT** · March 25, 2021 at 12:29 PM

This could be done via an addon, I don't think we have a getty in some addon though as that is an extremely niche usecase (building your own image and enabling the busybox getty applet and providing systemd unit files to enable it would be another possibility).

Keep in mind that a password on a serial console provides rather low additional protections. Once you have physical access to the device to hook up a serial console you could as well just take out the SD card and do everything you want (reading/modifying the data, enabling debug shell etc).

And if you go to the effort of securing physical access to the SD card you could as well secure access to the serial console pins - eg by putting everything in a metal box with a lock.

so long,

Hias

kia_rst · March 25, 2021 at 3:31 PM

What you mentioned is exactly what I have in mind,

the device is in a metal box with lock and there is no physical access to the SD card or the device it self and there is no network connected.

So in case I want to change something on LE, I was thinking of providing access to the UART console from outside the box so I wont have to open the box every time. just plug in a cable and make the changes.

This is a rare use case of course, but that is why I need to secure the shell on UART. So only the person with the key to the box or the password of the UART shell can make changes to the system.

Yes I have looked over a hundred addons and none of them were providing a getty on LE.

Actually I have built my own system image of LE (squashfs), So if you could literally point me in the right direction, I might be able to bring getty on my own image.

Thank you.

**HiassofT** · March 26, 2021 at 10:39 AM

To enable busybox's getty simply change busybox's target configuration to have CONFIG_GETTY=y - see here LibreELEC.tv/busybox-target.conf at master · LibreELEC/LibreELEC.tv · GitHub

You'll also need a systemd unit (and enable it) so getty is automatically started. In LE we remove getty.target and the serial-getty@ template, have a look at the latter systemd/serial-getty@.service.m4 at main · systemd/systemd · GitHub as a starting point. Yu need to adapt the agetty options to busybox's getty options and can simply use a fixed device instead of a unit template and let it install to multi-user.target - the TTY settings in the Service block should be fine though.

so long,

Hias

kia_rst · March 27, 2021 at 11:42 AM

I will try to follow your instructions to achive this goal and I will get in touch with you if I had furthur questions.

Thank you for help.