We have to be careful with this. By running essentially a firmware based OS you inherently accept two things relevant to OS security:

 

1. You will never get security fixes as fast as the upstream OS
2. You place a level of trust that the OS vendor (in this case Limetech LLC) is deciding on your behalf what is a serious risk and what is not.

In some ways this breaks with traditional "security in depth" which requires at its core you patch every security issue immediately regardless of perceived threat or more importanly your perception of that threat (since the days that someone can understand all-things-security and know how-all-servers-are-deployed in the wild are long since gone).

 

For these two reason alone unRAID can never by definition be as secure and a non firmware based OS and you should plan your security policy accordingly.

 

However for this cost along with a reduced uptime you get a lot in return not least of which is the ability to reinstall at a whim the whole OS.

 

This is why you need to be careful when discussing CVEs etc because the way you keep your other servers secure cannot be the same as the way you manage unRAID security.

 

There is room for improvement in the current model but it is important to set the scene that unRAID is no longer inherently insecure by design.

 

We are using slackware as a base for a lives in RAM OS.

We can patch just about anything, excepting emhttpd and the kernel

all @limetech has to do is push out a package ie samba-5.0.0-x86_64-6.3.3_limetech.txz and have it installed in the /boot/extra (We'll need web ui support for this)

you could turn the array off and install the package, the start the array. BAM! fully patched and vulnerability fixed, while limetech continues getting the patch rolled into the next release

since it was installed in /boot/extra, the patch takes over every restart.

the limetech could insert /boot/extra cleanup code in the next release so once the new version started it would nuke or disable the old patches

I don't see why running on a ramdisk precludes patching, when plugins can do it, the core system should be able to.

 

@ken-ji yup you are not the first person to have this idea. Currently this solution is not implemented, planned or supported and is specifically what I meant by " the way you keep your other servers secure cannot be the same as the way you manage unRAID security ".

 

I dont think we should try to push LT into a new real time test and release model and we are probably going off topic here. If anyone wants to start a new threat to create a security community working group to head up these things I will actively join in but I dont have the time to front something of this level of effort at the moment.

On 3/24/2017 at 5:14 PM, ljm42 said:

I just noticed that as of yesterday (3/23) there is a new issue for samba (SSA:2017-082-02):

 

Thanks for getting this into 6.3.3!

hello
Talking about security.
I wonder if there someday will be a part of the GUI to manage users and groups and share/folder permitions?

I see that all files and folders on my systems have permition 777, not that this is a problem normaly, but it would just be a nice option to have.

6 minutes ago, isvein said:

hello
Talking about security.
I wonder if there someday will be a part of the GUI to manage users and groups and share/folder permitions?

I see that all files and folders on my systems have permition 777, not that this is a problem normaly, but it would just be a nice option to have.

UnRAID does not really have the concept of users and groups at the Linux Level, so there is no incentive to support this.    Users for shares are already supported by the GUI.

12 minutes ago, itimpi said:

UnRAID does not really have the concept of users and groups at the Linux Level, so there is no incentive to support this.    Users for shares are already supported by the GUI.

I also see that if you change the user and group from the shell, it does not stick, it bounce back to "nobody:users" after a short time.

So this means that I cant setup an FTP/SFTP server for anyone but myself, even over ssh, since all will have access to everything.

2 minutes ago, isvein said:

So this means that I cant setup an FTP/SFTP server for anyone but myself, even over ssh, since all will have access to everything

 

No, FTP works with user names and associated rights as defined under users.

2 minutes ago, bonienl said:

 

No, FTP works with user names and associated rights as defined under users.

Yes, and every user on the system has acccess to everything if they first have access over FTP.

I just tested this with an user that over SMB does not have access to the share "test", but over FTP the user had access to everything in the "test" share", both upload and download.

Do you use the built-in FTP server?

 

yes

1 hour ago, isvein said:

yes

Sorry I wasn't clear earlier. This is expected behavior, see help function.

 

Overview

unRAID includes the popular vsftpd FTP server. The configuration of vsftp is currently very simple: All user names entered above are permitted to access the server via FTP and will have full read/write/delete access to the entire server, so use with caution.

 

There is a separate proFTP plugin made by SlrG, you may want to give that one a try.

 

5 hours ago, bonienl said:

Sorry I wasn't clear earlier. This is expected behavior, see help function.

 

Overview

unRAID includes the popular vsftpd FTP server. The configuration of vsftp is currently very simple: All user names entered above are permitted to access the server via FTP and will have full read/write/delete access to the entire server, so use with caution.

 

There is a separate proFTP plugin made by SlrG, you may want to give that one a try.

 

nice that one does what I want.

Untangle has a next generation firewall for home users now.  I protects all the computers from bad evil sites as well blocking inbound connections.

The home version is only 50 year for all modules.  We use it at work and is stable. I even set one up for my dad to block unwanted ads.

The built in VPN for both outbound tunneling and inbound is great. Runs on most hardware. 

http://www.untangle.com 

 

 

Note that an advanced user can make use of iptables to limit which hosts may access the device and the different service ports.

 

It's also possible to block all access to the web pages and require the user to use ssh to tunnel the web access. But to meaningful, the sshd has to be reconfigured to preferably only accept key-based authorization.

 

If an advanced user wants to do that then they are better off using any distro of Linux they want, the wouldn't be interested in unRAID and all it's 'limitations'.

It is more work to set up a full system from scratch than to tweak a bit with the sshd configuration and make use of iptables.

 

And there aren't that many alternatives to unRAID if you want parity and want to avoid having the data multiplexed over all drives. It takes a bit of time to set up a well-working Snapraid-machine too. Then it's quicker to tweak the security on a unRAID machine.

Right but you were talking about an advanced user, for them, everything you describe should be a walk in the park, even setting up dockers.

 

You can't have your cake and eat it too, in other words, you can't have the flexibility of a vanilla linux distro and all the goodies that Lime-Tech bakes into their product and then on top of that want more flexibility to change things that Lime-Tech locks down.

16 minutes ago, ashman70 said:

Right but you were talking about an advanced user, for them, everything you describe should be a walk in the park, even setting up dockers.

 

You can't have your cake and eat it too, in other words, you can't have the flexibility of a vanilla linux distro and all the goodies that Lime-Tech bakes into their product and then on top of that want more flexibility to change things that Lime-Tech locks down.

 

Might be a walk in the park when debating how hard to do.

 

But will take quite a bit of time from when you stand there with the hardware and zero software until you have set up everything with firewalling, supervision, SMART-scans, mail reports, docker infrastructure etc.

 

When you integrate 100 different functionalities then you also have to look into the configuration of all these 100 modules and remember what interaction you want and what interaction you need and to verify that you really do get the result you intended and didn't forget that single copy of value "1" to some file in the proc file system.

 

I didn't ask for more flexibility - I just noted that a skilled person can append own functionality on top of what is already there. Locking down sshd and add some restrictive iptables rules is way quicker than building a system from scratch.

It could have firewall like proxmox has at pools, host, VM and container level