[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672523#comment-15672523 ] Joseph Witt commented on NIFI-3050: --- andy - am a huge +1 . thanks for pushing this. It is certainly time and we have the basic ingredients to start taking meaningful steps here. I do think though ListFile is ok to not have as Restricted and I also don't think we need to do anything special with flow file attributes at this stage. Do you agree? > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672543#comment-15672543 ] Andy LoPresto commented on NIFI-3050: - I agree that the special attribute on downstream flowfiles should be pushed to a later effort. I had originally written it as a "nice-to-have" and forgot to note that here. I think there are scenarios where {{ListFile}} can be used maliciously, but with less impact than the others noted. Examples: * enumerating Kerberos tickets on the machine * listing unencrypted backups or "load scripts" which may be used to ingest unprotected raw data into data storage systems * determine existence of special admin tools, etc. in a specific directory * determine which files in a directory are readable by the running user (may be used to determine which user NiFi is running under) None of these actions are explicit attacks without additional work via shell or other external action, so I am not adamant about including this processor in the list. > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672558#comment-15672558 ] Matt Gilman commented on NIFI-3050: --- Should the Restricted annotation be supported on Controller Services or Reporting Tasks at this point or should we be solely focused on Processors? > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672563#comment-15672563 ] Joseph Witt commented on NIFI-3050: --- in my opinion it should be for the extension points/components. The subject should say "Restrict dangerous components to special permission". This means Processors, Controller Services, Reporting Tasks. > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672571#comment-15672571 ] Andy LoPresto commented on NIFI-3050: - Would you consider {SSLContextService}} a dangerous component? What about {{SiteToSiteProvenanceReportingTask}}? > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672647#comment-15672647 ] Joseph Witt commented on NIFI-3050: --- Let's define what it means for a component to be considered "Restricted". Proposed definition: A Restricted component is one that can be utilized to execute custom code provided by the operator through the NiFi REST API or one which can be used to obtain or alter data on the system nifi is executing on using the credentials NiFi is executing as. These components could be used by an otherwise authorized user of the system which could go beyond the intended use of these components and could expose data about the internals of the NiFi process or the system NiFi is operating on which should be considered privileged tasks that need to be specially limited. ...maybe not a great definition. But with that viewpoint in mind I don't think SSLContextService meets that criteria. I do think SiteToSiteProvenanceReportingTask does though as it would allow the user to access to raw provenance data outside the normal REST API controlled authorization model. For each component we tag as restricted we should document as part of the annotation the 'why' of it being restricted so that we can provide that information through documentation and the UI. For example GetFile should be @Restricted("It can be used to obtain the contents of any file accessible to the NiFi process on the system.") > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672742#comment-15672742 ] Andy LoPresto commented on NIFI-3050: - Ok, building on that, my definition would be: {quote} A **Restricted** component is one that can be used to execute arbitrary unsanitized code provided by the operator through the NiFi REST API or can be used to obtain or alter data on the NiFi host system using the NiFi OS credentials. These components could be used by an otherwise authorized NiFi user to go beyond the intended use of the application, escalate privilege, or could expose data about the internals of the NiFi process or the host system. All of these capabilities should be considered privileged, and admins should be aware of these capabilities and explicitly enable them for a subset of trusted users. {quote} I concur with exposing reasoning for each classification in the documentation and with your determination on {{SSLContextService}} vs. {{SiteToSiteProvenanceReportingTask}}. > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672749#comment-15672749 ] Joseph Witt commented on NIFI-3050: --- +1 > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673059#comment-15673059 ] Pierre Villard commented on NIFI-3050: -- +1 great discussion It'll need to be well documented but will provide a better security management. One question: how the backward compatibility will be ensured? Meaning: what will be the behavior when started NiFi with an existing workflow containing restricted processors? A message like "insufficient permissions, please contact the administrator"? > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673664#comment-15673664 ] Andre commented on NIFI-3050: - +1 > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673707#comment-15673707 ] Matt Gilman commented on NIFI-3050: --- Including support for Controller Services and Reporting Tasks seems correct to me, even if we don't offer any Restricted implementations with the distribution. Thoughts on decoupling the listing of users who can view Restricted components and those that can modify Restricted components? Is supporting a user that can view the Restricted components but not modify a valid use case (obviously assuming that access is otherwise granted)? > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673737#comment-15673737 ] Joseph Witt commented on NIFI-3050: --- [~mcgilman] I'd propose that users who cannot create instances of components which are restricted be able to see them and it errors when trying to add them OR we show them but grayed out and they cannot select them. We could do the easier path first and a more refined user experience later as well. What I'd like to avoid is them not even seeing those components in the listing because then they might be too confused. I think it is totally fair game for users who have otherwise normal read/write access to a component to be able see them but/view them but they should not be able to start/stop/configure them. Sound fair? > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673797#comment-15673797 ] Matt Gilman commented on NIFI-3050: --- Sounds good to me. Just wanted to clarify. Thanks! > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673805#comment-15673805 ] Mark Payne commented on NIFI-3050: -- I would also be sure to include `TailFile` as a `@Restricted` processor. This processor allows you to essentially access the contents of any file on the file system that the user running NiFi has access to. > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673850#comment-15673850 ] Andre commented on NIFI-3050: - I will check tomorrow morning Australian time but I suspect *HDFS can also be used to read local files (by using anx XML file with defaultfs property and file://as value) > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15674423#comment-15674423 ] Andy LoPresto commented on NIFI-3050: - [~trixpan] that is a good catch. As [~markap14] pointed out above, {{TailFile}} is another that can read arbitrary files. After further discussion, we also think {{ScanAttribute}}, {{ScanContent}}, and {{ReplaceTextWithMapping}} (as they can read a dictionary file from disk) may be candidates. I'd like to get a consensus here of how extensive we think this coverage should be vs. usability. > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15674501#comment-15674501 ] Joseph Witt commented on NIFI-3050: --- I see the point with ScanAttribute, ScanContent, and ReplaceTextWithMapping but I think given the scope of their use and the exposure they don't rise to the level of requiring restricted access on par with the others we've noted. This does highlight the need to perhaps offer tiers at some point but for now I think we've found a solid initial defensible sweetspot. I agree with Get/Fetch/PutHDFS being restricted use processors given their local file system implications which can run using native process permissions. > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15675659#comment-15675659 ] Andre commented on NIFI-3050: - +1 to [~joseph Witt] comment. Many processors will use other files as input to certain activities (the upcoming ExtractGrok has the same approach) but I am not sure we should include them as "restricted" per se. The issue with those I suspect, would be restricted to error messages that could contain snippets of the target file. (e.g. using /etc/passwd as ScanContent dictionary could result in data spill through error messages). Perhaps one thing we should consider, is the ability to "chroot" paths used by NiFi processors, that is , to restrict the DFMs to child paths of a particular directory in the filesystem (the root path would be configured via properties, similarly to what happens with the zookeeper "chroot"). If we decide to follow this approach, we would have to go around looking at processors making sure that "File.open" type of operations are wrapped with a check against the results of [getCanonicalPath or via Security Manager|https://www.securecoding.cert.org/confluence/display/java/FIO16-J.+Canonicalize+path+names+before+validating+them] > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15677790#comment-15677790 ] ASF GitHub Bot commented on NIFI-3050: -- GitHub user mcgilman opened a pull request: https://github.com/apache/nifi/pull/1247 Introducing restricted components which require additional access NIFI-3050: - Introducing a Restricted annotation for components that require elevated privileges to use. - Updating the new Processor, Controller Service, and Reporting Task dialogs to include these details and prevent unauthorized selection. - Including the Restricted description in the generated component documentation. - Updating processor access control integration test to verify restricted component creation. - Updating the developer, user, and admin guide to include the restricted component policy. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcgilman/nifi NIFI-3050 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1247.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1247 commit 890c42bb79d9b57ce7ed3e4d547337d76e741bc1 Author: Matt Gilman Date: 2016-11-18T21:19:04Z NIFI-3050: - Introducing a Restricted annotation for components that require elevated privileges to use. - Updating the new Processor, Controller Service, and Reporting Task dialogs to include these details and prevent unauthorized selection. - Including the Restricted description in the generated component documentation. - Updating processor access control integration test to verify restricted component creation. - Updating the developer, user, and admin guide to include the restricted component policy. > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Andy LoPresto >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15680338#comment-15680338 ] Andy LoPresto commented on NIFI-3050: - I commented on [PR 1247|https://github.com/apache/nifi/pull/1247] with my feedback on the proposed solution. I really like it and had some minor suggestions to improve user experience, including: * increased visibility of restricted icon/textual indicators on existing components on canvas * searchability of restricted processors in Add Processor dialog * increased visibility of restricted information in component documentation (currently, only present at the bottom of the documentation page). I think a large icon or other indicator at the top of the documentation, which could link to the additional description or explanation of risk at the bottom, would be valuable * an auto-generated canonical list of restricted processors, controller services, and reporting tasks should be created at build time and populated into the documentation (and available on the main documentation site) to be quickly enumerated I did positively verify the behavior of the proposed solution and just wanted to bring the discussion of these enhancements back to the main conversation to get commentary. I noted in the PR review that I am ok merging the current work as it satisfies the Jira and filing these enhancements separately as a minor issue if necessary for time constraints on the vote. > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Matt Gilman >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15684638#comment-15684638 ] ASF subversion and git services commented on NIFI-3050: --- Commit 7f5eabd603bfc326dadc35590bbe69304e8c90fa in nifi's branch refs/heads/master from [~mcgilman] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=7f5eabd ] NIFI-3050: Implemented access control logic for restricted components. - Addressing comments from PR. - Adding restricted tags to relevant components. - Showing a restricted icon overlay on the processor node on the canvas. (+1 squashed commit) Squashed commits: [f487682] NIFI-3050: - Introducing a Restricted annotation for components that require elevated privileges to use. - Updating the new Processor, Controller Service, and Reporting Task dialogs to include these details and prevent unauthorized selection. - Including the Restricted description in the generated component documentation. - Updating processor access control integration test to verify restricted component creation. - Updating the developer, user, and admin guide to include the restricted component policy. This closes #1247. Signed-off-by: Andy LoPresto > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Matt Gilman >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15684639#comment-15684639 ] ASF subversion and git services commented on NIFI-3050: --- Commit 7f5eabd603bfc326dadc35590bbe69304e8c90fa in nifi's branch refs/heads/master from [~mcgilman] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=7f5eabd ] NIFI-3050: Implemented access control logic for restricted components. - Addressing comments from PR. - Adding restricted tags to relevant components. - Showing a restricted icon overlay on the processor node on the canvas. (+1 squashed commit) Squashed commits: [f487682] NIFI-3050: - Introducing a Restricted annotation for components that require elevated privileges to use. - Updating the new Processor, Controller Service, and Reporting Task dialogs to include these details and prevent unauthorized selection. - Including the Restricted description in the generated component documentation. - Updating processor access control integration test to verify restricted component creation. - Updating the developer, user, and admin guide to include the restricted component policy. This closes #1247. Signed-off-by: Andy LoPresto > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Matt Gilman >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-3050) Restrict dangerous processors to special permission
[ https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15684642#comment-15684642 ] ASF GitHub Bot commented on NIFI-3050: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1247 > Restrict dangerous processors to special permission > --- > > Key: NIFI-3050 > URL: https://issues.apache.org/jira/browse/NIFI-3050 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Andy LoPresto >Assignee: Matt Gilman >Priority: Blocker > Labels: security > Fix For: 1.1.0 > > > As evidenced by [NIFI-3045] and other discoveries (e.g. using an > {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance > after the application has already decrypted the sensitive properties from the > {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve > {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized > users to perform malicious actions. While no tool as versatile as NiFi will > ever be completely immune to insider threat, to further restrict the > potential for abuse, certain processors should be designated as > {{restricted}}, and these processors can only be added to the canvas or > modified by users who, along with the proper permission to modify the canvas, > have a special permission to interact with these "dangerous" processors. > From the [Security Feature > Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]: > {quote} > Dangerous Processors > * Processors which can directly affect behavior/configuration of NiFi/other > services > - {{GetFile}} > - {{PutFile}} > - {{ListFile}} > - {{FetchFile}} > - {{ExecuteScript}} > - {{InvokeScriptedProcessor}} > - {{ExecuteProcess}} > - {{ExecuteStreamCommand}} > * These processors should only be creatable/editable by users with special > access control policy > * Marked by {{@Restricted}} annotation on processor class > * All flowfiles originating/passing through these processors have special > attribute/protection > * Perhaps *File processors can access a certain location by default but > cannot access the root filesystem without special user permission? > {quote} > [~mcgilman] and I should have a PR for this tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)