[ https://issues.apache.org/jira/browse/NIFI-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15896580#comment-15896580 ]
ASF GitHub Bot commented on NIFI-3054: -------------------------------------- Github user trixpan commented on the issue: https://github.com/apache/nifi/pull/1551 @joewitt thanks for your comments. I understand your concerns but isn't the user change of the default settings (we do ship with default location settings after all) a voluntary action that implies further changes? The way I see is a bit like: should Microsoft not ship Windows with default folder structures and permission just because someone may decide to install an application straight into c:\? We by now know many users will not read the administration guide before playing with the platform (and sometimes rolling it to prod), what I am trying here is to help those users from harm caused by setting up what is for all intends and purposes a remote execution environment. The scenario I am trying to address here is: Think of someone who install NiFi in AWS instance, using the default settings as a linux service. That user went far enough to create a nifi user. Any attackers could: - Find instance - Add ExecuteScript processor - Change `$NIFI_HOME/bin/nifi.sh` to obtain persistent control over the node (note that when running as a service, this is still run as root, with the privilege drop happening WITHIN the script, not before) - Use the machine to launch DDoS against users. A normal answer would be: Just change the permissions of `$NIFI_HOME/bin`. Fair enough! But the challenge is that due to to the way Unix/Linux ACLs work, in order to truly change the settings of `$NIFI_HOME/bin` you must change the settings of `$NIFI_HOME`, otherwise you can always: - Move the `bin` to `bin.old` - Create a new `bin` directory - Copy all content from `bin.old` the new `bin` - Modify `nifi.sh` - Wait for system to restart Source: [1] To prevent the simple 3 steps above, we must change the permissions of $HOME_NIFI And the problem is: We cannot change the permissions of $HOME_NIFI without creating the directories representing the default settings, otherwise would crash on start, unable to start (due to permissions). So long history short, the idea here isn't to randomly create things where we don't need them, I am just trying to avoid we fall into the MongoDB track of "shipping with insecure default settings" as this can easily tarnish a project reputation (my LinkedIn feed was full of sales rep from competitors spreading the word about MongoDBs ransomware woes). Hope this helps to clarify what the objective of this PR is. [1]The first 3 steps of this technique is so old that I can't find references to it anymore, but IIRC, affected the good old SunOS 4.1.3. The two other steps have been used by me many times in PenTests. > NiFi requires write access to . upon start > ------------------------------------------ > > Key: NIFI-3054 > URL: https://issues.apache.org/jira/browse/NIFI-3054 > Project: Apache NiFi > Issue Type: Bug > Reporter: Andre F de Miranda > Assignee: Andre F de Miranda > Labels: security > > As part of NIFI-1500 we identified that NiFi's current packaging requires the > $NIFI_HOME folder to be writable by the process that runs NiFi itself. -- This message was sent by Atlassian JIRA (v6.3.15#6346)