ESA 2016-061 - EMC Isilon OneFS SMB Signing Vulnerability
I am running OneFS 7.2.1.2 so i downloaded the patch README file and i am shocked.
INSTALLATION/REMOVAL IMPACTS
During installation or removal of this patch, the service that manages SMB,
NFS, HDFS, and Swift client connections as well as authentication to the cluster
is restarted. As a result, during installation or removal of the patch, client
connections to the cluster over these protocols might be disrupted and new
client connections cannot be authenticated. FTP and HTTP connections might be
affected in some environments, and client connections might have to be
reestablished manually after the installation or removal process is complete.
Is this really saying that in order to address this SMB vulnerability i have to essentially take entire cluster offline because my SMB/NFS users will be booted off anyway? Please someone tell me it's not so.
this is brilliant, so before i would only have to disconnect my SMB clients and now i have to shutdown my entire business just to install a SMB patch. This is some enterprise platform you are developing over there.
It's true, NFS was moved to user space in order to take advantage of the zone functionality amongst other things. It now runs under the lwsm container. So if a patch needs to be installed and services within lwsm need to be restarted both SMB and NFS will be effected.
who's brilliant idea was it to lump everything together ? How do i explain to my business that in order to install a patch to address SMB vulnerability i have to disconnect NFS users from the cluster ? I am talking about business critical applications like PeopelSoft, Blackboard, Apache, Tomcat ?
Incidentally, I discovered this weekend that this likewise loveliness means that if LDAP (at least, possibly AD as well) is somehow screwed up and likewise is dizzy, you can't log into the webui either, and sshing to or even between nodes is painfully slow.
In cases where a patch requires us to restart the likewise container, all services within would be restarted as well. In OneFS 7.2 and later, it will look something like this:
# /usr/likewise/bin/lwsm list
lwreg [service] running (5712)
flt_audit [driver] running (5726)
flt_audit_nfs [driver] running (5798)
isi_cpool_rdr [driver] running (5726)
lsass [service] running (5739)
lwio [service] running (5726)
lwswift [driver] running (5904)
netlogon [service] running (5716)
nfs [driver] running (5798)
npfs [driver] running (5726)
onefs [driver] running (5726)
onefs_lwswift [driver] running (5904)
onefs_nfs [driver] running (5798)
rdr [driver] running (5726)
srv [driver] running (5726)
srvstate [driver] running (5726)
srvsvc [service] running (5932)
svcctl [service] running (5932)
winreg [service] running (5932)
Note: NFS, lwio, and swift protocols are all in this container. In my testing, restarting the likewise service manager (lwsm) will restart all services in the container.
I hear your frustration but there may be an easier answer to this. to first hit the why, it was at many users request to get NFS the ability to work outside of the system zone that is my understanding of why it is now in userspace and tied to likewise not saying there might not be flaws but that is how I understand the reason.
I would recommend that instead of restarting the lwsm service you might get by with performing a rolling reboot. this will cause the lwsm services to be restarted on that node vs taking everything down at the same time. though you may have to have users remount or map for these changes to take effect
lastly I would provide this feedback to any executive level contacts you have and get some feature requests going. having executive level sponsorship to help push this along wouldn't go amiss either. part of the reason these things go through changes is that we are not closed off to changing the way the product works and if we can improve it we do.
The forum is likely not the best place to get this taken care of and probably better to get this in front of your account team and might even get some SR's going to help push the fact that your not getting NDU with security patches but I think the ideal workaround is to do a rolling reboot.
others can reply if that is effective enough, many times it requires clients to remount/remap for those changes to actually take effect so it is possible I am wrong only trying to help give you some options here and again an SR would be the best option or even waiting for the next MR for upgrade as an option vs patch but I personally know its not always viable when security is at the top of most of our minds.
I am not even going to waste my time with SR, it will go to support guys and they have no control over how Isilon architects their systems. I will be advised to contact my local account team which i had already ..and guess what i got from my team, absolutely squat.
I really want to understand why engineering decided to create one service responsible for both protocols ? Did someone take into consideration how that may impact future patching, upgrades ?. Does it mean that if i kill lsassd or lwiod i will disconnect NFS clients as well ?
I am game to do a rolling reboot, tell me how i would go about installing the patch without complete disconnect for NFS clients.
dynamox
11 Legend
•
20419 Posts
•
87439 Points
1658
4
Posted May 26th, 2016 12:00
this is brilliant, so before i would only have to disconnect my SMB clients and now i have to shutdown my entire business just to install a SMB patch. This is some enterprise platform you are developing over there.