I am running Unifi SDN controller 5.9.29-11384-1 on Ubuntu 18.04 LTS with HWE kernel 4.18 on Intel core i3 server.
My setup also includes 2 APs, USG and USW
During implementation of recommendations of security audit /tmp folder got 'noexec' mount flag which basically means files cannot be executed there. With this change, Unifi SDN Controller stopped working immediately because unifi java launcher cannot run snappy file from tmp:
java.lang.UnsatisfiedLinkError: /tmp/snappy-1.1.4-852edc30-7743-4c22-86c2-e611f1579fd4-libsnappyjava.so: /tmp/snappy-1.1.4-852edc30-7743-4c22-86c2-e611f1579fd4-libsnappyjava.so: failed to map segment from shared object
I have googled a bit for the similar issues (unfortunately I am not a Java expert) and found similar issues for Hadoop and other packages. In order to workaround the issue I have tried following proposed solutions:
- set -Dorg.xerial.snappy.tempdir=/newpath
- set -Djava.io.tmpdir=/newpath
but none of the above helped. OTOH when "noexec" parameter dropped from /tmp folder everything is working fine.
With all of the above, I would like to request following:
- Is it possible to use native libsnappy instead of the one supplied with unifi controller?
- Is it possible to somehow configure unifi controller to use other than /tmp folder for running executables (which is extremely insecure)?
Looking forward for your help and support
8 hours ago
It is pretty weird that nobody is inrerested in this. This means that either nobody cares about security or solution is well known to everybody except me.
8 hours ago
It's not that nobody cares, but it's not considdered a real issue to have execution privelidges on /tmp, since any access there should be handled by other security measures already. If any process/script on your system can execute anything without proper safeguards, you have a bigger problem than the /tmp directory. ;-)
A lot of "audit" tools are pretty poor, and often err on the side of "caution" because those who built them (and those who use them) don't really understand the implications of these things. Security is not easy, but the first line of defense is to keep people out of the machine entirely. Disabling execution in /tmp is designed to keep desktop users from executing dangerous scripts in downloaded files - not really a problem on a server...
"Humans are allergic to change..They love to say, ‘We’ve always done it this way.’ I try to fight that. "Admiral Grace Hopper, USN, Computer Scientist
":It's not Rocket Science! - Oh wait, Actually it is... "NASA bumper sticker
":The biggest problem in tech I see right now is that most users don't want to do things that are hard. That doesn't bode well for the industry or the society.": (me. actually ;-)
7 hours ago - last edited 7 hours ago
@eejimm, thanks for the comment, I see your point.
But IMHO noexec on "open" tmpfs still makes sense because AFAIK some rootkits use /tmp this way during deployment phase (unfortunately I do not understand that process in details yet).
Also, the tool I am using for audit is Lynis - which is not considered to be "poor" in any way :-) and I am not following all its recommendations blindly.
One more thing - overall, extracting custom executable to /tmp folder every time service starts seem to me like a "bad engineering practice", but of course I am not familiar with UBNT codebase to judge.
-- BR, Artem