@MSGID: lycpz@news.chiark.greenend.org.uk>
c8eff21b
@REPLY: 1@dont-email.me> ffb448fb
@REPLYADDR Theo
<theom+news@chiark.greenend.org.uk>
@REPLYTO 2:5075/128 Theo
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
lycpz@news.chiark.greenend.org.uk>
@RFC-References: 1@dont-email.me>
0Q9oz@news.chiark.greenend.org.uk> 1@dont-email.me>
@TZUTC: 0100
@PID: tin/1.8.3-20070201 ("Scotasay") (UNIX)
(Linux/5.10.0-22-amd64 (x86_64))
@TID: FIDOGATE-5.12-ge4e8b94
pozz <pozzugno@gmail.com> wrote:
> This post refers to Linux root user that isn`t normally exposed to the 
> end-users, mostly if I disable SSH service.
> 
> My concerns are for someone with sufficient technical skills that wants 
> to enter the Linux system. The first thing he would do is finding the 
> console UART, connect/soldering a USB/UART converter, open putty and try 
> to login guessing the root password.
> 
> The original question was for this scenario.

It depends whether the customer is your adversary or not.

If you want to prevent the customer having access, eg because hacking the
device would cause them to get free service or similar, then preventing root
access is a roadblock for this.  Or if the device has users whose motives
aren`t aligned with the customer (eg it`s installed in a public place where
people might tamper with it).

If the customer has bought the equipment and there is nothing the customer
or their users can illicitly gain access to, I`d suggest leaving a default
root password on there - it enables the customer full access to a device
they own and have physical access to, and gives them options for extending
the use of the device once its original purpose is ended (eg if you stop
supporting it).  If they choose to break their device, that`s their problem.

(some devices set a `warranty void` bit if unauthorised firmware is loaded,
to avoid having to handle warranty claims on modified devices.  Only some
SoCs have such non-resettable `e-fuses`)

I`m also assuming there are no other interfaces which might render any
password protection moot - like being able to unplug the flash storage and
change the password in another machine, or being able to use JTAG to
reprogram the flash chip.  If so, it may be simply a matter of difficulty -
pulling an SD card is easy, soldering to testpoints to access JTAG lines
less so.

One other thing, though.  If you have a fixed root password, make sure you
ensure that regular user processes can`t `su` to root.  Otherwise any
networked user who is able to inject shell commands can get root.

Theo
--- tin/1.8.3-20070201 ("Scotasay") (UNIX) (Linux/5.10.0-22-amd64 (x86_64))
 * Origin: University of Cambridge, England (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441