root and security

[h00g]

I'm security minded and would like to hear which operations of the script that require root access.
If, for instance, just some options require root access and others can execute fine at lower permissions then it would be beneficial to know.

It could also then be an improvement idea to separate the script into several parts where those operations requiring root were in sub scripts.

Further, I've not found the source code to /bin/dtc in this repository. Where can is be found in order to do code review from a security standpoint?

Having a tool running as root that downloads a binary file from an online repo, installs it and executes it as root may be seen as something worth investigating.

[007revad]

I got the dtc binary from one of these repos, which all have the exact same dtc binary:

1. https://github.com/pocopico/tcrp-addons/tree/main/dtbpatch/releases
2. https://github.com/PeterSuh-Q3/tcrp-addons/tree/main/dtbpatch/releases
3. https://github.com/jumkey/redpill-load/tree/develop/redpill-dtb/releases

So maybe one of them knows where the source for that dtc version is located. I searched the Xpenology forum but searching for 'dtc source' found too many irrelevant results.

Let me know if you find the source for dtc as I'd like to add it my repo, or at least a link to the source.

Commands that need sudo in syno_hdd_db

Notes

1. I tested with v3.4.80
2. Line numbers might be slightly different to v3.4.79
3. I tested with the -nrs options.
4. I did not test with the --restore or --check options.
5. I did not test the script updating itself to a newer version.
6. I tested on a NAS where the script had previously been run so nothing actually needed editing.
7. I only tested on a DS1821+ with a E10M20-T1 and 3 NVMe drives and no expansion unit.

Due to 4, 5, 6 and 7 there may be more commands that need sudo that I didn't find.

Line	Command
305	lvdisplay
306	pvdisplay
317	rm
326	rm
525	synosetkeyvalue
534	sed
535	sed
540	cp
547	cp
556	set_section_key_value
557	set_section_key_value
563	cp
570	cp
581	cp
595	cp
606	rm
611	rm
622	synosetkeyvalue
693	synosetkeyvalue
702	synosetkeyvalue
711	nvme
748	grep "$(basename -- "$1")" /proc/mounts
765	syno_hdd_util --ssd_detect
818	/run/synostorage/disks/nvme0/
819	synostorage
821	for d in /sys/block/*
962	grep: /var/log/diskprediction/data-2024-01-15.json: Permission denied
1087	sed /var/lib/disk-compatibility/ .db file
1097	sed /var/lib/disk-compatibility/ .db file
1107	sed /var/lib/disk-compatibility/ .db file
1191	sed
1196	sed
1277	set_section_key_value
1279	set_section_key_value
1296	sed
1463	dtc /etc.defaults/model.dtb to /tmp/model.dts
1464	chmod /tmp/model.dts
1478	dtc /tmp/model.dts to /etc.defaults/model.dtb
1481	chmod to set the original permissions on edited dtb file
1482	chown to set the original owner on edited dtb file
1483	copy /etc.defaults/model.dtb to /etc/model.dtb
1540	synosetkeyvalue
1551	synosetkeyvalue
1569	synosetkeyvalue
1580	synosetkeyvalue
1595	synosetkeyvalue
1604	dmidecode -t memory
1632	synosetkeyvalue
1646	synosetkeyvaluev
1681	synosetkeyvalue
1685	synosetkeyvalue
1715	synosetkeyvalue
1719	synosetkeyvalue
1747	synosetkeyvalue
1751	synosetkeyvalue
1771	sed
1772	sed
1792	synosetkeyvalue
1820	sed
1821	sed
1869	synostgdisk --check-all-disks-compatibility

[descilla]

I was a bit worried about finding a binary without a clear origin in this repo as well. The mention of the three repos above was not able to satisfy my security concerns (especially after the recent xz-nightmare). So I decided to consult virus total.

As expected no virus was found. However my actual concern was to get more informations about the origin of this binary. On the detail page you get the information that the binary was build by using gcc ((Debian 8.3.0-6) 8.3.0). However it seems the dtc is not obtained from a debian package but moreover build by the tinycore community itself since the only relations shown on the virus total homepage are tinycore-redpill-0.10.0.0.zip and inycore-redpill-main.zip.

Since I was not satisfied by this Source (in my personal opinion) I tried to use the dtc from a Debian package. Since newer ones had unresolvable dependencies I ended with using the dtc from the device-tree-compiler package for Debian Buster (Debian 10) which works perfectly fine for the syno_hdd_db.sh script.

I'm writing these lines for everyone with the same concerns like me. Since I assume the most people are happy with the current solution I will not open a dedicated issue for that.

Anyways: Thank you for your awesome scripts to make Synology usable again. :)

Greetings,
Simon

[007revad]

Did the script actually use the dtc file? The dtc file is only needed if your Synology meets 2 conditions:

1. Has an m.2 drive installed in a E10M20-T1, M2D20, M2D18 or M2D17.
2. Is one of the models that use a device tree blob.