Eadword Posted May 17, 2019 Share Posted May 17, 2019 (edited) 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. Edited May 21, 2019 by Eadword Appended contributed ideas 6 1 Quote Link to comment
bonienl Posted May 17, 2019 Share Posted May 17, 2019 I suggest you put this under feature requests, there it will stay more visible for any future development. Quote Link to comment
xanvincent Posted May 20, 2019 Share Posted May 20, 2019 On 5/17/2019 at 1:42 AM, Eadword said: [snip] 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. @Eadword: I have a thread opened for Docker Isolation with no replies, but you should add Linux namespaces / subuids for Docker to your list, as well as not using root and 777 permissions everywhere in the OS would be some good changes. It's been this way for a long time, I doubt it will change because unraid has always been a "don't expose to outside world" kind of distro for a long time. 1 Quote Link to comment
unRate Posted August 17, 2019 Share Posted August 17, 2019 (edited) https://forums.unraid.net/topic/84628-sane-security-defaults/ Edited November 21, 2019 by unRate Quote Link to comment
itimpi Posted August 17, 2019 Share Posted August 17, 2019 1 minute ago, BRiT said: A bump does nothing. What needs to be done is what BonieNL already said, post this in Feature Requests. And probably as multiple requests as one giant one is unlikely to gain much traction. Instead it needs to be a number of smaller requests that can be individually prioritised (if accepted) and gradually picked of. 1 Quote Link to comment
bonienl Posted August 20, 2019 Share Posted August 20, 2019 On 5/20/2019 at 5:02 PM, xanvincent said: I doubt it will change You should have more trust in Limetech Security is an important aspect and Limetech is constantly looking at improvements. 2 1 Quote Link to comment
Ryonez Posted September 13, 2019 Share Posted September 13, 2019 On 8/20/2019 at 7:35 PM, bonienl said: You should have more trust in Limetech Security is an important aspect and Limetech is constantly looking at improvements. Any chance there are some updates? The lack of docker isolation is actually starting to worry me as I do have a few external services I host on unRaid. Quote Link to comment
bonienl Posted September 13, 2019 Share Posted September 13, 2019 5 minutes ago, Ryonez said: The lack of docker isolation Please explain Quote Link to comment
Ryonez Posted September 13, 2019 Share Posted September 13, 2019 (edited) 21 minutes ago, bonienl said: Please explain The lack of `Docker Isolation through Linux namespaces / subuids`. I've been given the example over here that if someone breaks out of a container when they are root, they are root on the host as well. Edited September 13, 2019 by Ryonez Added link Quote Link to comment
bonienl Posted September 13, 2019 Share Posted September 13, 2019 Any link to that example ? Quote Link to comment
Ryonez Posted September 13, 2019 Share Posted September 13, 2019 1 minute ago, bonienl said: Any link to that example ? Yup, I linked it with a edit shortly after. Sorry, I didn't think when I posted it to add it. Quote Link to comment
bonienl Posted September 13, 2019 Share Posted September 13, 2019 Ok, but is there somewhere a "proof of concept" to confirm the claim? Quote Link to comment
Ryonez Posted September 13, 2019 Share Posted September 13, 2019 (edited) I don't know. I'm a little reliant on others knowledge here as I'm by no means an expert and what I do know is rather patchworked. Edited September 13, 2019 by Ryonez Quote Link to comment
bonienl Posted September 13, 2019 Share Posted September 13, 2019 It shouldn't be possible to "break out" of a container and as far as I know this isn't possible. Otherwise it will be a security vulnerability of Docker itself. Quote Link to comment
Ryonez Posted September 13, 2019 Share Posted September 13, 2019 Alright, thank you. I might poke around this subject more myself later. Quote Link to comment
NAS Posted September 23, 2019 Share Posted September 23, 2019 This is a pretty big deal if it is true. I wouldnt know how to pull this off right now though so more details required. Quote Link to comment
xanvincent Posted November 7, 2019 Share Posted November 7, 2019 On 9/13/2019 at 3:31 PM, bonienl said: It shouldn't be possible to "break out" of a container and as far as I know this isn't possible. Otherwise it will be a security vulnerability of Docker itself. It is definitely possible to break out of containers. This was 'recently' exploited successfully per CVE-2019-5736: https://www.twistlock.com/labs-blog/breaking-docker-via-runc-explaining-cve-2019-5736/ This was more a vulnerability of runC, not docker itself. It was, of course, patched some time after the CVE was identified. The point to using namespaces here is, if an exploit like the above is used on a container you're making available to the world, you want to minimize damage to the host system. With namespaces implemented, even if you escaped as root, you'd be some non-usable user on the host system, instead of root on Unraid. This is also a big reason not to use 777 permissions on the host OS too. Let's say your public container was compromised with such an exploit, now I have access to all of the data in all of your shares. 1 Quote Link to comment
kyle1 Posted November 18, 2019 Share Posted November 18, 2019 On 11/7/2019 at 11:55 PM, xanvincent said: With namespaces implemented, even if you escaped as root, you'd be some non-usable user on the host system, instead of root on Unraid. Is this similar to how Linuxserver allows you to specify a UID and GUID for their containers? It defaults to 999 and 1000; am I correct to assume that this means that the container user would be 999/1000 if they were to break out of the container, and thus be non-usable on the host? Quote Link to comment
xanvincent Posted November 18, 2019 Share Posted November 18, 2019 30 minutes ago, kyle1 said: Is this similar to how Linuxserver allows you to specify a UID and GUID for their containers? It defaults to 999 and 1000; am I correct to assume that this means that the container user would be 999/1000 if they were to break out of the container, and thus be non-usable on the host? Based on what I know about LinuxServer.io's docker containers, this simply maps the internal user of the docker (abc?) to the specified UID and GID. AFAIK, this does not affect the root user in the container. It would also only apply to LSIO containers. If someone knows different, feel free to correct me. I believe the only way to change the root user mapping (that is needed for interfacing with the host's resources) is with namespaces ie. --userns-remap USER. Quote Link to comment
kyle1 Posted November 18, 2019 Share Posted November 18, 2019 (edited) 2 hours ago, xanvincent said: is with namespaces ie. --userns-remap USER. Understood. Is this currently possible to do? Users created via the GUI would likely not be sufficient (still have rwx but not sudo), so you would probably need to create a user at boot to map to, then map tothat user in container options. Speculation on my part, however. Edited November 18, 2019 by kyle1 Quote Link to comment
xanvincent Posted November 30, 2019 Share Posted November 30, 2019 On 11/18/2019 at 4:47 PM, kyle1 said: Understood. Is this currently possible to do? Users created via the GUI would likely not be sufficient (still have rwx but not sudo), so you would probably need to create a user at boot to map to, then map tothat user in container options. Speculation on my part, however. The PGID and PUID commands map to an internal user (abc) within the container that runs and owns files for whatever app. Root still exists there (in the container) and that's the problem. Root id in container = root id outside of container. Implementing userns is THE fix for this security concern but has to be implemented at the command line when the container is run. 1 Quote Link to comment
SpencerJ Posted August 3, 2020 Share Posted August 3, 2020 7 hours ago, Be-Art said: I am hoping to move Joomla (CMS) built sites to my unraid build and expose to the internet. Reading up on name spaces, so i can implement docker containers safely. Anyone have any suggested reading or experience from doing the same or similar setup? Would you mind creating your own thread for this question? You will likely get better results 🙂 Thanks Quote Link to comment
trurl Posted August 3, 2020 Share Posted August 3, 2020 Just now, SpencerJ said: Would you mind creating your own thread for this question? You will likely get better results 🙂 Thanks Already split into this thread: 1 Quote Link to comment
SpencerJ Posted August 3, 2020 Share Posted August 3, 2020 Just now, trurl said: Already split into this thread: Wonderful. thks Quote Link to comment
unRate Posted August 14, 2020 Share Posted August 14, 2020 On 9/13/2019 at 7:31 PM, bonienl said: It shouldn't be possible to "break out" of a container and as far as I know this isn't possible. Otherwise it will be a security vulnerability of Docker itself. Which does happen. https://unit42.paloaltonetworks.com/docker-patched-the-most-severe-copy-vulnerability-to-date-with-cve-2019-14271/ Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.