4 ms·

Unraid is not confidence inspiring either. It's just more commercial closed source software, developed behind closed doors and with a slow update cadence (~3 mo

Unraid is not confidence inspiring either. It's just more commercial closed source software, developed behind closed doors and with a slow update cadence (~3 months). They have made questionable security choices anywhere you can see, and I have strong doubts that their code quality is any better. The PHP scripts certainly are a horrible mess, in all ways. For example, shell injection prevention is based on using escapeshellarg at each call site... that pattern is _exactly_ the structural root cause for vulnerabilities like the one D-Link had. In no particular order, and obviously not exhaustive: Everything runs directly as root - nginx, php-fpm, smb, ... No AppArmor/SELinux. There is no Secure Boot support (especially unfortunate since boot is from USB stick). No HTTPS access to web frontend by default. SMB protocol defaults are insecure. SMB shares default to public. SSH allows password-based root login. Pools are unencrypted at rest by default. They have a checkbox to enable telnet for management! Very permissive iptables rules. Almost any features that real competitors like Synology would officially provide come from third parties via a moderately shady app store. Note it's not about any of these individual points. I see above as signal that they are not security experts and see security as an afterthought, rather than as something that deserves a team of experts that specifically cares about it. (There's certainly other fields they also aren't experts in, like UX - their predominant UI pattern is "list of dropdown fields". Even in storage, one could have a longer discussion how their Array feature - the true core of their product -, compares to modern solutions. There's a reason they've evolved cache pools to just pools as a separate thing, and some users do pool-only Unraid...) That's all quite understandable since it's a small team with only 2-3 coders (https://unraid.net/about https://unraid.net/about). But nevertheless.

ffsm8 2y ago
> Everything runs directly as root - nginx, php-fpm, smb, For the record: you need root on Linux to open ports below 1000. By necessity, these programs need at least one thread that runs as root just from that. Can't comment on the rest. As I never used it. Fedora server + cockpit UI was enough for me when I switched from my Synology NAS the other day
- matthews2 2y ago
  You can drop root after binding, or you can use capabilities to allow a particular program to bind on privileged ports. php-fpm could listen on a UNIX socket instead of a TCP socket.
  - Ao7bei3s 2y ago
    Exactly. A more modern secure approach is to let the init system open the socket and pass it as an FD. This has some side benefits too (not even temporary root for daemon, less custom code, standard&declarative config, socket activation). (Of course Unraid, being based on Slackware, has a legacy init system that doesn't support this scheme. But there are enough other options.)
- deleted 2y ago
  [deleted]
- arp242 2y ago
  You can use cap_net_bind_service to bind ports <1024. You can listen on >1024 and redirect in iptables, or even with a trivial TCP proxy. There are options on pretty much any system, but certainly on Linux with capabilities. None of these require direct support from the application (dropping root after binding does). You almost never need to run anything as root, especially not with these "run 6 different types of services in a box" type of appliances. None of this is new; this was already widely considered best practice when I was starting out 25 years ago.
  - duskwuff 2y ago
    > There are options on pretty much any system, but certainly on Linux with capabilities. If you're using systemd, you can grant the appropriate capability to the process by setting: [Service] AmbientCapabilities=CAP_NET_BIND_SERVICE in its service file. Note that this will necessarily allow the process to listen to any port; there is, unfortunately, currently no way to lock it down to a single port.
    - deleted 2y ago

ffsm8 2y ago

> Everything runs directly as root - nginx, php-fpm, smb, For the record: you need root on Linux to open ports below 1000. By necessity, these programs need at least one thread that runs as root just from that. Can't comment on the rest. As I never used it. Fedora server + cockpit UI was enough for me when I switched from my Synology NAS the other day

matthews2 2y ago
You can drop root after binding, or you can use capabilities to allow a particular program to bind on privileged ports. php-fpm could listen on a UNIX socket instead of a TCP socket.
- Ao7bei3s 2y ago
  Exactly. A more modern secure approach is to let the init system open the socket and pass it as an FD. This has some side benefits too (not even temporary root for daemon, less custom code, standard&declarative config, socket activation). (Of course Unraid, being based on Slackware, has a legacy init system that doesn't support this scheme. But there are enough other options.)
deleted 2y ago
[deleted]
arp242 2y ago
You can use cap_net_bind_service to bind ports <1024. You can listen on >1024 and redirect in iptables, or even with a trivial TCP proxy. There are options on pretty much any system, but certainly on Linux with capabilities. None of these require direct support from the application (dropping root after binding does). You almost never need to run anything as root, especially not with these "run 6 different types of services in a box" type of appliances. None of this is new; this was already widely considered best practice when I was starting out 25 years ago.
- duskwuff 2y ago
  > There are options on pretty much any system, but certainly on Linux with capabilities. If you're using systemd, you can grant the appropriate capability to the process by setting: [Service] AmbientCapabilities=CAP_NET_BIND_SERVICE in its service file. Note that this will necessarily allow the process to listen to any port; there is, unfortunately, currently no way to lock it down to a single port.
  - deleted 2y ago