I have recently started to look into BorgBackup as backup solution. So, I had the idea to set it up on my Synology NAS.
I installed Borg on my NAS, set up a dedicated Borg user and Borg share, made sure only the Borg user had access to the share, and made sure the Borg user has no access to anything but the Borg share (it can’t even sign in to DSM or anything, to be extra safe) and everything seemed fine so far.
I think I got “privilege separation” figured out for this. But here’s the problem:
Apparently, since about DSM v6.2.2 (that’s the OS), it’s not possible for normal users to sign in to SSH anymore. It’s only possible for users in the “administrator” group to sign in to SSH.
And here’s the real problem: Anyone in the “administrator” group, gets full access to all shares, to all system settings, to all software packages, to all configs, and even to a root shell.
So, Synology’s idea was this: Let’s not give normal users shell access.
This makes sense as a default, except in this case it’s not just a default! You can’t disable this setting!
So, Synology is forcing users to give anyone admin (root) rights to get SSH access, which is LESS secure. It completely undermines privilege separation.
I think the intention might have been good, but the execution was not thought out, at all.
“Hey, look, you either grant full (root) access or no access at all. Fine-grained permissions? Hahaha no.”
And the sad thing is, while looking into this, I found several users online setting up things by simply giving the user full admin/root access, to bypass this problem. Synology has achieved the opposite effect, and is drastically lowering the security of its product by forcing users to make poor setups and killing privilege separation.
How it should have been done
Synology should have made this option the default, with a possibility to disable it, and grant normal users shell access.
Or better yet, create an “ssh” group or similar that has access to SSH, and let admins decide which users go into this group, i.e. fine-grained control over who can SSH.
But the current state is just madness.
I looked around online, it seems there’s no setting in the UI, and not even a config file/option anywhere. Synology seems to ship a custom build of OpenSSH with this dumbass decision hard-coded. The only fix seems to be to compile OpenSSH yourself and manually install it. However, this is the sort of system modification I wouldn’t do on an integrated product like this.
Perhaps I could install a dropbear binary somewhere (it can be compiled into a single binary, so this sort of modification can be easily undone/shouldn’t mess with the system) and have it run on a non-standard port, just for BorgBackup…
While I mostly like Synology NAS, they sometimes do not-well-thought-out things like this. The intention being good, the execution being terrible and achieving the opposite effect.
I now statically cross-compiled dropbear for the NAS, and it works! I’ll have to harden it and deploy it as a proper service before I use it, though. (:
Update 2 (Feb 22nd, 2022)
I did sign in to a Synology NAS running DSM 7.0 just now, and got this message:
Synology strongly advises you not to run commands as the root user, who has the highest privileges on the system. Doing so may cause major damages to the system. Please note that if you choose to proceed, all consequences are at your own risk.
Exactly my point! So let users sign in to SSH without admin rights… 🤦🏻♀️
Leave A Comment