Security Policy Discussion


limetech

Recommended Posts

Long time moderator and user NAS brings up an important point:

 

For what it is worth RC4 is probably vulnerable to a kernel level MITM CVE-2016-5389. I have not posted this is the security sub forum because what is the point, no one ever acknowledges me and it certainly doesn't impact the timing of a fix.

 

I think it important we keep focused on what has been asked here because it really is pretty simple; there has to be a privacy policy because unless LT has made a considerable effort not to track personal data the typical name, address, IP, version will be stored in various places. This is to be expected by any online business but thats why a privacy policy is needed.

 

As for CVEs, I have made my case for this countless times. We need a security patching policy. This is an absolute requirement as due to the "firmware" nature of the product it can ONLY be patched completely at source. This does not need to be much and at its heart is simply a commitment to patch the release product once every XXX days/weeks/months under normal circumstances and an emergeny time line for critical issues. It should also have a basic "report a security issue" privately procedure.

 

With the exception of the actual patches the above is at most an evening work. As an OS manufacturer it not really optional and certainly to sell in the EU/UK the privacy policy is a legal requirement (luckily its 30 mins effort copying someone elses like everyone else does).

 

Why cant we simply debate this to conclusion? Why cant we help get it done? I just dont get why its silence or push back every year its brought up.

 

In regards specifically to CVE-2016-5389, that is addressed in linux kernel 4.4.19 which is incorporated into 6.2.0-rc5.

 

In regards to an official Policy, refer first to:

https://lime-technology.com/forum/index.php?topic=42640.msg494275#msg494275

 

Ok well what I can say now is that with 6.2 we are taking a slightly different development approach which will hopefully permit us to respond more rapidly to CVE issues (and other bugs).  Once 6.2 'stable' is released we will be adopting the same approach taken in the linux kernel:

- there will be a unRAID OS 'mainline' which is the equivalent of "next release" -rc/-beta.

- there is the latest 'stable'

 

We are setting up a method to monitor CVE releases (still working on making that less 'manual'), but when a CVE is released that effects us, or a critical bug is found, we will first incorporate into 'mainline', test, and then back-port to 'stable', releasing a new 'stable' immediately.  The 'mainline' may or may not be also released immediately, depending on the nature of development at that point.  (But 'mainline' is for beta/rc which already should be run in more confined environments.)

 

Well that's the plan.  Re: making specific time deadlines, e.g., "we promise to incorporate a CVE with N days of being aware of it" - is not really practical given our small team size.  But we will make a promise that CVE's will be given highest priority when they arise.

 

Link to comment

As with the other posts this is also excellent and gets another thumbs up.

 

Two suggestions:

 

1. You really should consider an addon that lets you push out trivial package security updates. Your Nerd tools package "just works" and in my eyes at least you shouldn't need to build a whole new unRAID OS and ask your entire userbase to install and reboot just to for example update 2 lines within the curl binary which could be pushed out via an addon. I know this is a diversion from the way things are currently done but if nothing more it gives you more time/grace to issue a point release.

 

2. You do still need a CVE timeline. I would resist any urge to make it short but you need to set the scene for three reasons; if you dont people will just expect you to match whatever their internal policy is and since you havent set one to overide this just opens the door for complainers; also users should know at what point a report will definitely be fixed by, this is a must in any corporate environment; lastly users should know when they have a right to prod or even complain without fear of other users judging them by their own standards. Perhaps 1 month?

Link to comment

With regards to pushing updates, I think it is possible to have unraid apply packages found on the USB flash drive (maybe /boot/updates or /boot/patches) before actually starting any service (at the very start or runlevel 3?), this would allow patches to certain key packages be pushed out (curl, samba, nfs, ssh, ssl, key plugins) and allow the updates to take effect before anything in the unraid system irrevocably (more like annoying to restart) comes online; including patches to emhttp if necessary.

 

Why this hasn't been done?

 

Link to comment
  • 2 weeks later...

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.