unRate

Slackware is a Linux distro indeed. But unless you run unraid on top of vanilla Slackware yourself, then unraid is considered an "Appliance" by Limetech. Which translates to "We don't have to do security patches, nor do we need users, DAC, just run everything as root" They are not going to patch this. It will be updated in the next RC at best. These CVE's are already 4 months old! What I meant by my initial comment about using a proper linux distro is that if you care one bit about security use something that gets regular updates. e.g., Proxmox, TrueNAS scale, vanilla Linux, etc.

Then you need to be using a proper Linux distro :)

A newly discovered critical vulnerability in Samba could allow remote attackers to execute arbitrary code as root on affected installations. All versions of Samba prior to version 4.13.17 are vulnerable to the heap overflow memory handling vulnerability – providing they are running the flawed VFS module https://portswigger.net/daily-swig/critical-samba-flaw-presents-code-execution-threat

I'm pleasantly surprised to see you officially acknowledging this. This is definitely a step in the right direction. Looking forward to follow how "security over convenience" will be implemented.

Sure lets expose €%*@!*/# root to the internet. What could possible go wrong? Everyone advises against root login and not using key-pairs via SSH, and you want to allow your users — which by your own implications are incompetent sysadmins — to access root over https? You should at least use better defaults and apply the "Principle of least privilege" with layered security, before even considering rolling out remote access en masse. – Let alone using €%*@!*/# root passwords. As a reference take a look at the effort put in to secure cockpit-project by their engineers. I really can't fathom this nonchalant security mindset, hence the frustration.

Nope...

To be honest I find it kind of insulting, that you insinuate than I'm in the wrong. Had I been reporting an unknown exploit like this in the open I would have understood your response. But the CVEs I'm talking about are by their nature public knowledge... And some has been for over a year! Now we can agree that it certainly doesn't look good that I have to remind you of security updates... But that is entirely different from leaking exploits in a public forum, and could have been avoided by staying on top of very basic security. Your link to your Release methodology and excuses of bad habits doesn't help secure your customers unraid boxes. I'm disappointed in Limetech's mentally towards security in general. With this incident on top of the nonchalant attitude and implementation of security, it's definitely time to find another solution for my server.

Unraid is shipping vulnerable packages, some fixed over a year ago. Where's the security updates?

Which does happen. https://unit42.paloaltonetworks.com/docker-patched-the-most-severe-copy-vulnerability-to-date-with-cve-2019-14271/

My number 1 wish is better security https://forums.unraid.net/topic/80192-better-defaults/

https://forums.unraid.net/topic/84628-sane-security-defaults/

Disable the creation of .DS_store on network drives (Client side) defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true Log out/in to take effect Disable the creation of all ._ files (Server side) Stop the array Go to Smb settings & add the following to the "Samba extra configuration" field veto files =/._*/.DS_store/ Additional files can be vetoed if needed, just remember a trailing "/"