Better Defaults


Eadword

Recommended Posts

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 by Eadword
Appended contributed ideas
  • Like 6
  • Upvote 1
Link to comment
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.

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

  • Upvote 1
Link to comment
  • 2 months later...
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.

  • Upvote 1
Link to comment
  • 4 weeks later...
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.

Link to comment
  • 2 weeks later...
  • 1 month later...
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. 

  • Like 1
Link to comment
  • 2 weeks later...
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?

Link to comment
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. 

Link to comment
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 by kyle1
Link to comment
  • 2 weeks later...
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. 

  • Thanks 1
Link to comment
  • 8 months later...
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

Link to comment
  • 2 weeks later...
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/

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.