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, 20197 yr by Eadword
Appended contributed ideas

I suggest you put this under feature requests, there it will stay more visible for any future development.

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.

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

Edited November 21, 20196 yr by unRate

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.

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.

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.

5 minutes ago, Ryonez said:

The lack of docker isolation

Please explain

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, 20196 yr by Ryonez
Added link

Any link to that example ?

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.

Ok, but is there somewhere a "proof of concept" to confirm the claim?

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, 20196 yr by Ryonez

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.

 

Alright, thank you. I might poke around this subject more myself later.

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.

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. 

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?

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. 

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, 20196 yr by kyle1

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. 

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

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:

 

Just now, trurl said:

Already split into this thread:

 

Wonderful. thks

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/