@MSGID: 1@dont-email.me> 3f2762db
@REPLY: lycpz@news.chiark.greenend.org.uk>
c8eff21b
@REPLYADDR pozz <pozzugno@gmail.com>
@REPLYTO 2:5075/128 pozz
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
0Q9oz@news.chiark.greenend.org.uk> 1@dont-email.me>
lycpz@news.chiark.greenend.org.uk>
@TZUTC: 0200
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.15.0
@TID: FIDOGATE-5.12-ge4e8b94
Il 31/08/2023 15:39, Theo ha scritto:
> 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.

It isn`t... usually :-)


> 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 simply don`t want some "smart" users with sufficient technical skills 
would be able to understand how the device does the things it does.
For example, sniffing the code of Linux scripts or Python code of 
proprietary software.

Maybe some "users" that work in competitors.


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

If there was infinite technical knowledge and money, it would be 
impossible to protect the device. Here I would like to stop only 
"medium/low" hackers.


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

Good point. Anyway, I think it`s valid if the root password isn`t fixed.

 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.15.0
 * Origin: A noiseless patient Spider (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