[
https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672742#comment-15672742
]
Andy LoPresto edited comment on NIFI-3050 at 11/17/16 5:00 AM:
---------------------------------------------------------------
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}}.
was (Author: alopresto):
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)
