Andre, I really like you starting this conversation. I think the PrivilegedProcessor annotation/marking and separate permission would be valuable, with the understanding that it’s addressing a specific threat — malicious DFM. Those processors can (even now) also modify the provenance, flowfile, and content repositories, the user database, the authorizations files, even nifi.properties directly. They could also be used to surreptitiously replace a NAR or some code being run within NiFi. So I see a lot of value in locking that down further.
I would want to discuss using MiNiFi to encapsulate privileged processors further because of interdependencies on controller services, etc. but it is certainly a novel approach and could be successful. Thanks for bringing these important issues to the list. Insider threat has traditionally not been the focus because there are so many attack vectors for a malicious admin or DFM to directly cause harm. I think we are at a stage as a community where more attention can be paid to these concerns and steps taken to mitigate them. Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Oct 3, 2016, at 7:56 PM, Andre <[email protected]> wrote: > > 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
