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.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
