All, As I have been working around restricting the level of filesystem privileges required by NiFi to run, I started to wonder how to tackle what in my opinion is one of the biggest challenges around NiFi:
How to ensure the ExecuteProcessors, FS processors (GetFile/PutFile) aren't misused by a rogue DFM. So that we are all in the same page, in theory it is possible for a rogue DFM with enough privileges (i.e. right to modify the flow), to overtake a NiFi environment completely: To achieve this, the attacker would: Step 1 - use PutFile to overwrite configuration files, in this case, the XML files with the access policies. Step 2 - use ExecuteScript ro restart the NiFi process[1] Given both NiFi and the ExecuteScript run as NiFi user, a security obsessed admin would have to use remove the processors, or use SELinux or similar technology to prevent the above scenario from happening. In light of that I have a few ideas I would like to share: 1 - Allow some processors to be marked as "privileged processors". This would cover processors that can make changes to the local system (ListFile, PutFile, GetFile, ExecuteScript, etc). 2 - Create an explicit privilege to control access to these "privileged processors". With 1 and 2 in place, Admins would be alerted to the impact of providing access to certain processors to their users. In addition, I would suggest the following: 3 - Consider segregating privileges within NiFi: As far as I understand, once the sudo_cmd_prefix is determined, NiFi will run its components as the run.as UID. Perhaps we could: a) Leverage MiNiFi and spin up JVMs to be used to run the privileged processors listed above. This of this as a "minifi container". b) Ensure user access control and processors are run under different UIDs, preventing the need of having the run.as user acessing the authentication files (e.g. conf/users.xml) Keen to hear your thoughts [1] I realize ExecuteScript could also be used to overwrite files in the FS.
