I wonder if removing all permission on the device file in /dev for the serial port would simply block all access to the serial port.
Locked down too hard and blocking the bad guys also blocks the good guys.
Secure the device and secure the location.
1 Like
That's cool...unless I'm missing something though, all I have to do is: reformat the NAND, hit the reset button or do a screwdriver rest...I'm not trying to loose this ability. I know reformatting the NAND will remove the firmware in its entirety, the other two should be as other OpenWRT devices (but I've also asked how the buttons work on MikroTiks).
I think this is the answer...this is a compile option, right?
This might be easier.
Thanks! Now I have some ideas...!
Without physical security what is to stop someone using the bootloader to backup an image of your flash, edit it offline or another device and then flash the new version without you knowing.
2 Likes
It was my hope not to veer of into the extreme...just the [non]malicious (playful) actor from trying to e.g. change passwords (or see passwords) on the online system, mostly. Things can be re-flashed and rekeyed if unauthorized long-term access (the hacker kid hanging out for an hour in the 'computer closet,' lol) to the offline device is in question. I understand that beyond hardened equipment, I'm only referring to the OS. Even hardened devices need physical security...after all, most can still be RESET. 
First, I was not aware you could make a backup of the flash using the bootloader...interesting to know...but I guess in any case, another ELF could simply be booted to read the flash...but again, this is extreme (in satisfaction to my question, at least). I'm simply "containing the obvious" and focusing on OpenWRT...so...
Any process beyond seeing the CLI and/or hitting f [ENTER] will likely take more than a few seconds...I rather an actor only have a chance to manipulate files offline - than online via the RS-232 port...the option to enable ttylogin will help most, and the ability to disable failsafe should cover most other (realistic) cases.
The most "security paranoid" thing it seems I may do is disable failsafe...but no one offered clarity if the erase flash button/screwdriver will still work...
Thanks all for your valuable input.
I found this page: https://openwrt.org/docs/guide-user/hardware/terminate.console.on.serial
Especially this line:
Note: If you need to use the terminal for RAW data/Modem data, then you need to reconfigure this terminal
/dev/tty*via coreutils-stty module.
Is this what you mean?
Totally different.
After the additional information you posted, I don't think a Serial Port Redirector applies.
1 Like
You can disable failsafe by either using the aforementioned option CONFIG_TARGET_PREINIT_DISABLE_FAILSAFE=y or by shipping a customized package/base-files/files/lib/preinit/30_failsafe_wait.
Note that failsafe and flash erase are different mechanisms, you can think of failsafe like a slightly more complex init=/bin/sh, means it will bypass the usual system init, setup a dummy ramdisk backed overlay filesystem and start dropbear in passwordless mode, dropping you directly into a root shell.
The flash erase on the other hand is the mere act of erasing the overlay flash partition, which will cause the system to come up with the build time squashfs defaults on the next boot.
Using CONFIG_TARGET_PREINIT_DISABLE_FAILSAFE will not disable the ability to reset the system to defaults but it will disable the press [f] to enter failsafe prompt.
4 Likes