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

I wouldn't expect anything before 6.9... Smh.

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?

Given a simple buffer overflow in the kernel and no additional info leak vulnerability, BlindSide can mount BROP-style attacks in the speculative execution domain to repeatedly probe and de-randomize the kernel address space, craft arbitrary memory read gadgets, and enable reliable exploitation. Project: https://www.vusec.net/projects/blindside/ Paper: https://download.vusec.net/papers/blindside_ccs20.pdf

Abusing Docker containers for privilege escalation

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

I'm not "simply complaining" I'm giving you my raw feedback on what it looks like to me from the outside. At the same time I'm looking for answers. I have asked you specific questions, a few posts above, which you conveniently danced around. Questions which link to past discussions on "specific attack vectors" By reading the forum, it is clear that I'm not the only one that have been concerned with the security of unraid for years... These specific weak points have been pointed out, none of them have been addressed... I'll ask again, is limetech going to make use of the Linux security features (Discretionary Access Control, default firewalls, SELinux, sudo, and file permissions, to name a few.), or should those who give a shuck move to another Linux implementation that does? I would very much appreciate an answer so that I can make a decision. Thank you.

First off that comment wasn't made by me, it was part of a reasonable and well written, similar concern from another user 3 years ago. Knowing now that limetech has hired a full-time web developer, (presumable the man behind the fancy new landing page, marketing and whatnot) while not prioritizing security, that comment resonated with me... When I say "[...] arguably nothing has been done to effectively improve security at the core." I mean that nothing has really been done to make the underlying Linux system more secure than it was 3 years ago. (DAC, MAC, SELinux, sudo, and file permissions, etc...) I'm not saying that I don't appreciate the various CVE patches, but that's not the point neither the problem.

Uhm... I feel like you are evading the question. With the tunnel vision of "Running as non-root would not have prevented this vulnerability" then yes the attacker would still have been able to bypass your authentication, and do arbitrary code execution. The big issue is that since the server is running as root, well he basically have unrestricted root/superuser access. Had the process been in a group with less permissions, further exploiting and privilege escalation would be needed to pwn the server... Throwing the core UNIX discretionary access control, and its extensions out the window is mind-boggling at best. "Unraid is an appliance" what does that even mean in this context? Regarding the blog post, it aids getting the best out of the current state of unraid security. It does nothing in addressing the essence of the original request; Namely is limetech ever going to implement DAC, MAC, SELinux, sudo, and file permissions, etc. - or should we move to another Linux implementation that does? I hate to do this, but it's done with tough love and in the interest of the average Unraid user. 3 years ago, you said "We take security very seriously" in a response to "I guess spending time adding eye-candy and stuff like that is more profitable than mundane security stuff, which is a very short-sighted approach." You have now hired a full-time web developer, with design and marketing experience. While arguably nothing has been done to effectively improve security at the core.

While I appreciate the transparency, this is exactly why running everything as root is a very bad idea. Is this request ever going to get at least a statement from limetech? Maybe it is time to build a proper Linux server and utilize it's security features.

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

While the current system is great for the average home network as a media server storing non-critical and non-confidential information on a private network, with a few changes, it could be ready for so much more... Where I'm coming from: I'm new to unraid, and I am a long time Linux-user with widows as a side OS I avoid as much as possible. Currently I've been setting up a VFIO system, and because I won't just be using it to store media but to actually be my daily driver, I have certain security concerns with the current default configurations. The following is a list of changes I've compiled, largely from http://kmwoley.com/blog/securing-a-new-unraid-installation/ and somewhat ordered by importance: - SMB 1 disabled by default - FTP and Tellnet disabled by default - HTTPS enabled with a self-signed cert out of the gate (love the cert authority setup though!) - make it more clear how to encrypt new drives (can't choose to encrypt when adding the device, has to be changed in the default filesystem setting) - new shares not exported by default, and when exportrd, Private by default - Don't export the USB boot media!!! (At least not by default and add an are you sure if you try to enable it) - firewall such as UFW installed and enabled by default with only TCP port 80 and 443 set to LIMIT and whatever SMB uses opened. GUFW could be pulled from for the GUI. And providing quick check boxes for common ports would make it easy, possiblity auto enabling when you enable a core service. - Docker Isolation through Linux namespaces / subuids - allow tagging more shares for direct Linux VM mounting to prevent the need to pass through /mnt/user - better multiple-user support, it's a server, right? So people other than root should be able to ssh in and access the UI; ideally root login would be disabled with use of a wheel group instead - don't use 777 permissions by default, ideally users + groups, but at a minimum there is no reason for most things to be read, write, and execute by default! - support for openvpn - support for multiple different encryption keys And add other lurking issues to this. Even if you're not exposing a system to the public internet, a lot of these things can still cause problems if the system is up 24/7. There is no such thing as a "friendly environment" outside air-gapped systems, and my daily driver will definitely not be air gapped. Anyway, if you've made it this far and feel like this is a list of complaints, I'm sorry. I do like unraid and I already feel excited for where it's going.

just use nfs?

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 "/"

I'm actually using ssh on my phone to start VMs yet it still happens

Just make a share for stuff you want on ssd and set to use cache only

I'm glad you patched it. Thank you! I'm curious though what's the problem with AVID? Other than the recent creation error, I do have some weird audio issues with that audio interface in VMs... Anything I can do until the next release?