[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)
