Jump to content

limetech

Administrators
  • Content Count

    9265
  • Joined

  • Last visited

  • Days Won

    123

Everything posted by limetech

  1. If you get this worked out, here's a thought. You could put the code and Makefile in a github repo and once other issues are sorted (such as udev rules) we can look at cloning repo and adding to Unraid OS. However, if a newer kernel comes along and now driver won't build, we'll have no choice but to file an Issue in the repo and omit the driver until issue is resolved.
  2. Something else I wanted to add, as long as we're talking about security measures in the pipe: we are looking at integrating various 2-Factor solutions directly in Unraid OS, such as google authenticator.
  3. I haven't "danced" around anything, sorry if it appears like that. How does this apply in an Unraid server environment? Yes this is something we're looking at. why? why? There is only one user: root You can set file permissions however you want using standard linux command line tools. Again, what are you trying to accomplish? We do have plans to introduce the idea of multiple admin users with various roles they can take on within the Management Utility. For example, maybe you create a user named "Larry" who only has access to the Shares page with ability to browse shares only they have access to. However this functionality is not high on the list of features we want/need to implement. Earlier you were confused by my term "appliance". What this means is the server has a single user that can manage the box. If you don't have the root user password, all you can do is access shares on the network that you have permission for, and access Docker webUI's - but most of these have their own login mechanism. Things like the flash share exported by default, new shares public by default, telnet enabled by default, SMBv1 enabled by default, etc. are all simplifications to reduce frustration by new users. Nothing more frustrating that creating a share and then getting "You do not have permission..." when trying to browse your new share. We are trying to reduce the swearing and kicking of dogs by new users just trying to use the server. Eventually everyone needs to be more security conscious - and in that spirit we are working on "wizards" that will guide a user to setting up the correct settings for their needs. I hope this starts to answer some questions and sorry if I came across flippant to your concerns, but trust me, security is a foremost concern and to have someone imply otherwise ticks me off to be honest.
  4. This is a load of B.S. While I appreciate the sentiment of your post (wanting to improve security), it is not helpful to simply complain. What is helpful is to point out specific attack vectors that we can address. Unraid is rapidly evolving from a simple NAS mainly used by tech-savvy home users to a more general platform with a wider range of users. It used to be the introduction of some bug that causes customer data loss that kept me up a night. These days, having a bug that presents a security risk is far more worrisome. So don't tell me we don't take security seriously. That said, there is a trade-off between making the server easily accessible for a first-time user vs. locking it down so tight no one can figure out how to even get in. I'll give you an example. By default we export the 'flash' share as a public share. Some people's hair catches on fire because of this. But the reason it's done this way is that after a user creates a bootable USB flash a very simple test is to see of the 'flash' share shows up in network explorer. There are other reasons it's handy to have this public for at least some amount of time. These days we have an icon next to the flash share if it's public, where rollover warns about this. Moving forward we are developing an initial configuration wizard that will guide a user in setting up the level of security appropriate for them.
  5. There is a ssh login attempt from an IP geo-located in China. But either your win10 VM has malware or maybe a Docker container has some kind of malware. Please provide a list of all your containers.
  6. Unraid is an appliance. There is only one user: root. We can rename to "admin" but it's still root. There are not traditional user logins. Users are only used to validate SMB connections. Running as non-root would not have prevented this vulnerability which btw, was a couple 1-line bugs. re: the request: we have a blog post that talk about this: https://unraid.net/blog/unraid-os-6-8-2-and-general-security-tips Sure I can go reply in there...
  7. Unraid OS Forum Moderators professional work space, sure beats google's!
  8. Something else to try: On Setting/Global Share Settings set Tunable (enable Direct IO) to Yes.
  9. Thanks for the link. I don't have any windows code development environment and as soon as I find the half a day to learn this and get it running, I'll take a stab. In meantime I'll do some testing with linux CIFS and see if I can reproduce similar results.
  10. We fixed this other bug first and since SMB is path based, if test program is generating a lot of lookups during write for some reason, could explain it Right, I'd be interested in hearing about a specific case, most things work fine. However, I realize there could be an app that breaks. Adding the line to SMB Extras is a quick test/fix, ultimately we'll make a per-share config setting for this. Which tool? Please provide link. Also debugging these kinds of issues is a 2-way street. This is not the only issue we have to work on.
  11. Please add this line in the "Samba extra configuration", see Settings -> SMB -> SMB Extras case sensitive = true And let me know if this makes any difference.
  12. Verified, yes that works. You only need to add a single line in SMB Extras: case sensitive = yes Note: "yes" == "true" and is case insensitive
  13. Wasn't sure 'case sensitive' was global - it's documented as per-share. For the other ones, those are current defaults.
  14. Pretty sure we got to the bottom of this. Turns out Samba operations on large directories has been problematic for a long time. It has to do with how case is handled with file names. google 'samba very large directories' for a good survey of the problem. With array Started, if you include this option for one of your shares in file /etc/samba/smb-shares.conf it will speed up: case sensitive = Yes After editing file type: samba restart You should see dramatic speedup. Unfortunately your edit will not be preserved across array Stop/Start. Also, there are a couple more options related to case, read about them here. (see below, just put 'case sensitive = Yes' in your SMB Extras settings. We will add a new share config option that specifies whether to set 'case sensitive' to yes or no.
  15. Correct. Actually the actual disk path of the vdisk is passed to qemu.
  16. Changed Status to Closed Changed Priority to Other
  17. For the record: Lime Tech highly recommends you do not turn off these mitigations.
  18. tldr: If you are running Unraid OS 6 version 6.8.1 or later, the following does not apply (mitigations are in place). If you are running any earlier Unraid OS 6 release, i.e., 6.8.0 and earlier, please read on. On Jan 5, 2020 we were informed by a representative from sysdream.com of security vulnerabilities they discovered in Unraid OS. Their report is attached to this post. At the time, version 6.8.0 was the stable release. The most serious issue concerns version 6.8.0. Here they discovered a way to bypass our forms-based authentication and look at the contents of various webGUI pages (that is, without having to log in first). Then using another exploit, they were further able to demonstrate the ability to inject "arbitrary code execution". Someone clever enough could use this latter exploit to execute arbitrary code on a server. (That person would have to have access to the same LAN as the server, or know the IP address:port of the server if accessible via the Internet.) Even in versions prior to 6.8.0, the "arbitrary code execution" vulnerability exists if an attacker can get you to visit a webpage using a browser that is already logged into an Unraid server (and they know or can guess the host name of the server). In this case, clicking the link could cause injection of code to the server. This is similar to the CSRF vulnerability we fixed a few years ago. In summary, sysdream.com recognizes 3 vulnerabilities: That it's possible to bypass username/password authentication and access pages directly in v6.8.0. That once authentication is bypassed, it's possible to inject and have server execute arbitrary code. That even if bug #1 is fixed, #2 is still possible if attacker can get you to click a link using browser already authenticated to your Unraid server (6.8.0 and all earlier versions of Unraid 6). Mitigations are as follows: First, if you are running version 6.8.0, either upgrade to latest stable release, or downgrade to an earlier release and install the sysdream mitigation plugin. We are not going to provide a mitigation plugin for 6.8.0. If you are running any 6.6 or 6.7 Unraid release, the best course of action is to upgrade to the latest stable release; otherwise, please install this mitigation plugin: https://raw.githubusercontent.com/limetech/sysdream/master/sysdream.plg This plugin will make a small patch to the webGUI template.php file in order to prevent arbitrary code execution. This plugin will work with all 6.6.x and 6.7.x releases and should also be available via Community Apps within a couple hours. We are not going to provide a mitigation for Unraid releases 6.5.x and earlier. If you are running an earlier release and cannot upgrade for some reason, please send us an email: support@lime-technology.com. I want to thank sysdream.com for bringing this to our attention, @eschultz for initial testing and fixes, and @bonienl for creation of the sysdream mitigation plugin. I also want to remind everyone: please set a strong root password, and carefully consider the implications and security measures necessary if your server is accessible via the Internet. Finally, try and keep your server up-to-date. VULNERABILITY_DISCLOSURE.pdf
  19. 'shfs' is our proprietary union-type FUSE file system implemented entirely in-house. Every access via /mnt/user/.. is via this file system, with some exceptions: if one of the loopback file systems, libvirt, docker, exist on /mnt/user we actually de-reference the file (find out what volume it exists on) and use that when mounting the loopback. similarly, vdisk images exsting on /mnt/user/.. are also de-referenced when starting a VM. The idea of bypassing shfs when all files of a share are guaranteed to exist on the same volume is on our to-do list and should get incorporated when we release multiple-pool support. You can use a bind mount to set this up yourself if you want. We're looking into the recent SMB slowdown this week to see what changed.
  20. Yes, log into console and type this command: inet restart If still no IP address you can copy the system log to the flash: cp /var/log/syslog /boot/syslog.txt This wils show up in root of flash device. Plug flash into PC to get it.