Andy, We are on the same page about the annotation and the surface of attack. I didn't want to list item by item but as you highlighted, when using a single user to run privileged sections of code and user land, everything is up for grabs.
Unless someone opposes I will be happy to raise a JIRA for the annotation and another one for the permissions. Regarding encapsulation, the idea is still quite incipient but I am keen to keep the ball rolling. Leaving aside the lack of integration, I wonder what would be the current limitations and dependencies of adopting such approach today? Is it correct to assume running some MiNiFi instances would be akin to have a number o NiFi instance f per entity (user, group, company, etc) talking with NiFi instances managed by other parties? Kind regards On Tue, Oct 4, 2016 at 2:24 PM, Andy LoPresto <[email protected]> wrote: > 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] <[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. > > >
